Fantastic Beasts and How to Taxonomize Them (A wizarding guide to the Drupal Taxonomy System)

>> TIMOTHY YODER:  Thanks a lot.  So, this is fantastic beasts and how to taxonomize them, a wizarding guide to the Drupal taxonomy system.  I am Timothy Yoder.  I'm a senior developer at Atla, collectors and connecters in religion and theology.  And I'm a lead developer on the internal Drupal system that powers Atla's library metadata assembly and distribution for the Religion Database product.  

And so this is a site building course, and it's a fairly basic one.  It's intended to help introduce newer site builders to how the taxonomy system works.  

With Drupal in general and the taxonomy system specifically, Drupal often has an issue with making its various functions so generic.  It's difficult to figure out what they are and how you can best use them.  

We may feel like we have a good grasp on what categories and tags are, but not what taxonomy is.  And categories and tags are good taxonomies, if what you're managing is the blog.  But if your site is doing something different than blogging, they are not the only metadata you would need to manage.  Drupal takes a step back with taxonomies and tries to make them more user configureable system that can be applied to any case you throw at it, which is a process we refer to as abstraction.  It makes the taxonomy system a little bit more powerful and harder to conceptualize, and that's why we're going to dive into it now.  Wands out!  

So, the department for the regulation and control of magical creatures advisory website is in an awful shape::  Everything is a jumbled mess on one page.  

Okay.  So, here's our fake site that we've put together.  And it's got a whole bunch of different creatures listed here, but you can see that it's just a standard bulleted list that's divided up and lord knows what organization is there.  It's all jumbled together, it's not even alphabetized.  But moreover, there's a lot of information that's very useful, a lot of depth, but it's just a link away.  But what link are you supposed to click on?  What link is going to be the helpful one?  

So what I want to point out here is the layout itself is information poor.  It doesn't give you a lot of guidance.  It's just take it or leave it.  Now, this is an intentionally bad example, but I don't think any of us have to think too hard to think of a site that has a lot of content, a lot of dynamic content but it's just hard to navigate.  And that's what we're talking about.  

This isn't helpful.  

So right now, if you put yourself in the user's shoes, what can you not do with this layout?  One thing you can't do is find a list of all the creatures that are dangerous.  The other thing, if you want a pet, you cannot find a creature that can be safely domesticated.  If you saw something interesting in the bog, you can't narrow the creature down by its habitat.  

So, big picture, what's wrong here?  This does not encourage user interaction and exploration.  Users might not spend long on the site, in other words.  Finding what a user is looking for is burdensome.  It puts a burden on the user.  And, you know, for a user who has a bad experience, they might leave and not return.  

And then last, this is bad for SEO.  If the page crawler can't make connections, the site's not going to rank well.  

So this is one of the first principles that we want to think about, organization itself is information.  Okay?  We'll just let that stand for a little bit.  

Organization is a way to present information, but itself, it's information as well.  And it makes an information rich site much more valuable.  

But first, what are taxonomies?  So, I'm making reference to    there's a great document there that's linked here, and it's linked at the end.  I don't have it in chat right now, but it is in the slide deck and I would recommend anyone who is interested in this topic, go ahead and grab the slide deck, it's uploaded to the node on the MidCamp website.  

They define taxonomy as the practice and science of classifying things, and in Drupal, the taxonomy module allows you to classify your website content, and it can be an important part of your information architecture.  

Taxonomy means assigning categories, tags, and other labels to our content in order to create meaningful relationships.  

In Drupal, your taxonomies are not predefined.  You can make them into whatever you want them to be.  And so when we're talking about how to make a taxonomy, the three things we want to talk about are vocabularies, terms, and then the relationship between the content and the term.  

Vocabularies are the collections we're going to make, the buckets.  They can be flat or hierarchical.  That means that they can have relationships between each other, or they can all be independent.  Okay?  

Then terms are individual segments belonging to a vocabulary.  They can be related to one another with parent child relationships if it's a hierarchical taxonomy, or they can be completely independent, as we mentioned.  

So, you know, that means that a vocabulary is kind of like a class, and then a term is an instance of that class.  

And then one more level down, we have relationships with the content.  They say that the content is an instance of a term or belongs to the term or has the term as an attribute.  And we may be limited to one term per content item or not.  You know, one content item might have multiple terms, depending on what makes sense for the vocabulary.  

So to be more concrete, we're going to go through some examples.  

So the first example is a flat vocabulary with only one relationship between the content and the term.  We're going to look at the Ministry of Magic classification.  This is our first vocabulary, our first taxonomy that we're adding.  Every creature listed, specifically beasts, because there is insulting to give to a being.  Every creature, every beast that's listed is going to have one of these five rankings.  It's either going to be one X for boring, two X for harmless, three if a competent wizard should be able to cope with it, four if it's dangerous or requires specialist knowledge, or five in it's a known wizard killer and impossible to train or domesticate and you're not asking Hagrid's opinion.  

The feature is that these categories are all independent from one another, meaning there isn't a relationship between them and one isn't nested beneath the other.  And in this case it doesn't make sense for a content item, a creature in this case, to have more than one classification.  

When something can't be both boring and a known wizard killer, for example.  

So we look at the flobberworm.  It's a boring creature, but the flobberworm is rated as one X, boring.  

Here's another example.  This is a flat vocabulary, but more than one relationship is possible.  We've created a category for the department of the regulation and control magical creatures type.  I added non being, which I'm sure for some fan purists is going to be controversial, but it's going to illustrate an important distinction I want to make later on.  So bear with me, if that bothers you.  

The features.  These categories are independent from one another, meaning that one is not nested below the other.  But there are some circumstances where the classification of a beast can be genuinely ambiguous.  Take, for example, the werewolf.  The terms we're going to use are both beast and being.  The relationship with the content, the werewolf.  Is classified as a beast and being depending on the state of the transformation.  

Now let's look at a hierarchical taxonomy.  Now, we're going to create a habitat as an example of this, because we're used to how habitats can be subdivided.  For example, forests can break down into temperate or rain forest types of forests.  Aquatic can be fresh water or ocean.  And obviously we can keep going with that.  A freshwater could be subdivided into lake or river.  Temperate forest could be coniferous or however you want to put it.  

But obviously, they're more complicated, okay?  These are categories that are related hierarchically to each other.  One way you can think about it is looking at the branching tree we have on the side.  Oftentimes, the relationships will form kind of a tree structure that moves backwards to a single or a smaller list of categories.  

So, these categories are related hierarchically to each other, and the forest is the parent of the rain forest and the rain forest is a child of the forest, but if you keep making connections like that, you get your tree shaped hierarchy.  And like we said, you can keep breaking these distinctions down as you like, but you should be careful not to overcomplicate things.  

Some cautions for using a hierarchical taxonomy.  If you read the Drupal 7 guide that I have linked, and yes, I know it's Drupal 7, but it's very good general advice for Drupal 8 and 9.  So hopefully, we see, you know, updates to the documents.  I think it's very much worth looking over.  

That document is going to tell you    and I'll tell you here too    nesting things too deeply adds unnecessary complexity.  For your own future sanity, you should try to select parent categories as well as child categories when you create the content relationships.  And we'll talk a little bit more about that.  

But, you know, basically, we'll talk specifically about creating the relationship between the contents and the term.  

What I'm saying here, though, is if you were to use rain forest, the rain forest biome as a habitat, it would be a good idea to put a check in forest as well so that if you ever need to create visualizations of everything that's forest, you wouldn't lose the things that are in a subtype, and if you created everything that was in a rain forest, it would also be exclusive upwards, so on, so forth.  

Obviously, there are ways to infer that relationship.  You know, this is a relational database underneath.  But honestly, keeping your data groomed ahead of time when it's possible is just going to make things a lot easier for you.  And keep your querying a lot simpler.  

So, we're looking at the Hippocampus.  This is a sea monster.  Part horse, part fish.  It would be an ocean aquatic habitat.  The relationship with the content, the Hippocampus is an aquatic    is aquatic and lives in the ocean.  I would ideally want to check both of those check boxes and say both aquatic and ocean, so that I can list all of the aquatic together as well as all the specifically ocean creatures.  

So, with that said, let's just take a quick breeze through how to set up our taxonomies.  And this is one of those drink through the fire hose sorts of things.  I've got a lot of screenshots, but that's why the slide deck is there to look at later.  We're just going to talk about how to actually make these work in the site.  

So, we're going to go back to the DRCMC advisory website.  We're going to add a new vocabulary.  We're going to call that creature capabilities.  These are the things that the creature is capable of doing.  

So I want to draw your attention to, first we've got a human readable name.  That's required.  There's also a machine readable name, creature_capabilities.  Now, that standard worm case meaning all lower case and the spaces are replaced with underscores.  That's going to be forcibly unique in the system.  And it's important because it might show up in things like URLs in the future, so you want to make sure that even though it's unique, you want it to be pretty human readable even if we call it machine readable.  Then we're going to give it a description.  The things the creature is capable of doing.  

All right.  And now here it is.  So in our list, you can see we've got a couple of other things in place such as the subtype, the habitat, the Ministry of Magic classification.  But second from the top is our creature capabilities.  

And if you look all the way on the right, there is a button that allows us to go to list terms.  And under that, we're going to add our first term.  So, under name, we're going to call it flight.  That's the ability to fly.  We'll save it.  And then we'll go ahead and we'll add a couple of other things.  Can it see in the dark?  Is it capable of speech?  Can it breathe under water?  Can it use fire?  Is it venomous?  Okay.  So, all those are terms that represent the creature capabilities.  

And now the next thing we need to do is add this creature to our content type.  And I want to say I've made a little bit of a lip here.  Previously, we were looking at the    we were previously looking at the taxonomy.  So, when you're in the administrative mode, standard Drupal 8 menu bar, administrative menu, under structure, we were in the taxonomy section.  We've now switched to content types and we're editing our creature content type.  We have created fields for all of these, everything that exists so far.  You'll notice the field type is entity reference.  If you're coming from Drupal 7, taxonomy terms used to be their own type of reference, but now they're kind of grouped together, entity reference in Drupal 7 could always reference taxonomies.  

But in the interest of simplification, everything is an entity reference now.  So we're going to add another field.  It's going to ask us what type we want.  You'll notice that it's grouped together.  General, number, reference, text.  Under reference, so that's an entity reference, we're going to select taxonomy term, which is going to confine our scope of what we can reference to terms.  We're not looking for files or users or content.  Once again, we're going to give it a label.  It automatically create asthma sheen name.  

In order to keep things simple, we're naming it the same thing as we're naming the vocabulary.  And we hit save and continue.  

And, you know, here we get to second guess ourselves.  If we decide oh, wait, I didn't actually want this to reference taxonomy terms, we can fill something different out.  But that's going to be prepopulated.  

Now, once again, we're talking about creature capabilities, and a creature can have a bunch of different capabilities.  So we're not going to limit the number of values, the number of relationships we can have.  So we'll save the field settings.  

All right.  And now we have one more screen.  This is a very important screen that's easy to overlook.  Under reference type, the most important thing is the vocabulary.  So, we may have named the vocabulary and the field the same thing, but it needs to know which vocabulary we're dealing with.  Otherwise, it would just allow you to choose from any term or multiple vocabularies.  

So, we're going to make sure that creature capabilities is selected.  The next thing too is I'm going to draw your attention down at the bottom under default value.  You can see that the widget type that we have is a set of auto completes, and, you know, you've got a bunch of different ways to make this relationship.  If you've got a large number of things in your taxonomy, which I would recommend avoiding for the most part for most situations, you'll want the auto complete because it will be a faster way to get through things.  But, in our case, we're going to stick mostly with check boxes.  

So, on the next screen, you'll notice that we just saved our new field.  Now we're going to go one tab over from managing fields to managing the form display.  Down at the bottom, as you can see, we defaulted to auto complete.  We're going to change that to check boxes/radio buttons.  And, you know, just a quick tip.  This is one of those pieces of visual vocabulary that we often forget we know about, but almost everyone knows that if you see check boxes, you can select multiple values.  If you see radio buttons, it's only one value.  And effectively, those two are almost always mutually exclusive.  

So Drupal intelligently knows if our cardinality, if the number of values we allowed is not limited or it's limited to more than one thing, we'll be presented with check boxes.  If it was something exclusive like the danger system, 1X through 5X, we get radio buttons and it would be the same selection.  All right.  

So, now let's move over to edit the dragon.  You can see a bunch of things that are already selected here.  The Ministry of Magic classification is already at 5X.  This is a beast.  We gave it    guessed at its habitat.  And under creature capabilities, we're going to tell it that it can use fire and it can fly.  Both of those are valid.  

All right.  So, that's a lot.  We've got all our content entered, but we need to go and fill out the relationship for every other beast that's in the system.  We've got a lot more features to sort.  

So when I call your name, you will put on the hat, sit on the stool to be sorted.  

Now that the taxonomies are in place, what can we do with them?  Let's redo that home page to group the creatures by type.  Okay.  And make it so that when you click a subtype heading, we go to a more informative page.  So this is as if we clicked through on the being type.  We can see that we have centaur and goblin and ogre and all these other beings listed.  They have their title, they have a thumbnail of their picture, and then they have an excerpt from their description, and that's a lot more informative than what we've had before, and we've only drilled in one layer.  

Now, we could if we wanted to create a page where this view is presented for everything.  But that's something we'll try to talk about a little bit further on.  

Okay, the next page is creature capabilities.  We now have a heading for every one of the capabilities that we just created.  Flight, sight in the dark, speech, underwater breathing, uses fire, venomous.  All of those creatures are relisted under those capabilities.  And you'll notice amongst other things, our friend the dragon is now listed twice.  It's listed four down under flight, and under uses fire, it's third from the top.  

And it's helpful because if you want a list of capabilities, you want it to appear twice.  And then last for this presentation, here's our ministry of magic classification.  It sorts all of the beasts out by how dangerous they are.  And you'll notice that this was the smaller list.  The reason this is the smaller list is because the classification only applies to beasts.  It doesn't apply to the others.  

And so if it doesn't have that relationship, if it's not rated, it's just not knowing up on this view.  All right.  

But now, I'm sure by now some people are thinking, how did we get here?  We're looking at web pages.  But all we did was create the taxonomic structure.  And, yeah.  There were some steps that we need to go over to show how we made that happen.  

So, that is the second secret part of this presentation, views integration.  So we talked about taxonomy.  Now let's just talk about how to use views with relationship to the taxonomy.  All right.  

To make the most of our new taxonomies, we need to use views.  Let's go over how you create the creature type view.  

So, once again, we're looking at an administrative dashboard.  We clicked on structure.  Views are down here at the bottom.  We're going to tell it to add a view.  And we've filled out some basic information.  We're looking at the DRCMC, subtype or type is what we called the view.  Our view settings, we're showing content of the feature type and we're sorting it by the title.  And then we're going to create a page for it.  

Now, you could also do a lot of other things with views that are beyond the scope of the presentation.  But suffice it to say, if you want it to have a random creature of the week show up, or if you want it to have interesting advisory sub parts show up on a side bar, that's what block settings would be for.  They work almost identically with page settings and a view can actually serve both of them.  That's why we have both check boxes.  

We're going to stick with pages just to keep the scope of the presentation confined.  So we're going to create a page.  And we're going to select    ideally, we'd want to select HTML list and a list of titles.  Items to display.  That's going to be a limiter.  That's going to make sure that only so much show up.  If the you don't want to use that, your choices are to set it at a very high number here, or on the next page, you can just remove the limiter altogether.  All right.  

So, what we have so far is we have a list of creatures.  We have no sorting that we've defined ourselves.  There's a default sort.  But it's just a bare list of creatures.  It has no relationship with the taxonomic terms that we're trying to bring in.  And so the first thing you need to do is expand the advanced section in the right hand corner and click add a relationship.  All right.  

And under that, you know, I want to point out once we're in most of the interfaces in the views, there are two filters at top.  There are very, very long lists of things that you can add as relationships and fields.  You can type into the search box or use the category drop down to narrow down what it shows you.  It can be very helpful.  You'll notice that I use that in later slides.  

So, we're creating a creature subtype view.  We want to create a relationship with the creature subtype.  You'll notice the relationship we're using is    under category, it says content.  We're building a relationship based on the field that is in our content.  So that field is referencing a taxonomy.  We are using the link in that field.  

And then because we only want to show things that actually have a subtype, we're going to check the next check box that says require the relationship.  It means that if the creature doesn't have a subtype assigned, we're just not going to show it.  I want to say for anyone who thinks in SQL already, you don't have to know SQL to work with views.  The main design is that that wouldn't be required.  But if it's already something you have available, I'm going to just kind of give a couple of tips on that.  This is the equivalent of using an inner join rather than a left join, okay?  

So, below our configuration interface, we have this preview pane and you can see that at this point, we don't have much, we just have a list of creature names that don't even link to anything yet.  So up under display, we're going to tell it    we're going to click on the fields link and title.  We're going to check the check box that says link to the content.  It means that all of those titles are now going to link to the content page that's much more useful.  We're not going to stop there.  We're going to click to add another field.  This is where we really start bringing our taxonomy in.  So I typed name up in the search box, and the category column is really helpful here to see what you're dealing with.  When I say name, you can see that the category is a taxonomy term.  So I'm going to click that and add the field, click the check box, and click add and configure fields.  

So I want to back things up just a little bit.  When we're talking about a taxonomic term, there are two pieces of information that are really, really important about a taxonomy term.  Okay.  One of them is the name.  The human readable part.  So, flight that we've already dealt with is really    is going to be what you are tempted to think of as being the taxonomy term.  

But, if you look up on the URL, it says taxonomy term 23 edit.  Okay.  That 23 is a very important number.  That is what we call the term ID, or TID.  And it's analogous with the node ID everywhere else for our content.  Okay?  And it is going to be the conical version.  If you think about it, under different vocabularies, you could feasibly have different taxonomy terms that have the exact same name.  And that would be confusing if you saw them altogether, not separated by the taxonomy term.  It can be a problem if you're trying to address the nodes programmatically and you only have their names.  

So, in the database, the term ID is really important and it shows up in some other places that we'll discuss at least in the appendix of the slide deck.  

So, the big thing is a term is an entity just like a node or like a user, and taxonomy terms also have unique IDs.  

All right.  So, going back, just going to go back here.  We've added the taxonomy term name, and we're going to add    the relationship is there.  It's provided by the field when we created the relationship earlier.  Because this bridge is necessary, you need that field to make a bridge between the content and the taxonomy term.  The relationship is already filled out, but there are other terms when you're making more complicated views where you might have multiple taxonomy terms linked for the sake of the view, and this is where you would need to tell it which one you're trying to reference.  When you just say I want to show the taxonomy name, it's like, great, which name are you talking about?  This is the one where we specify which field to get the taxonomy name from.  

Now, here's a place where this can be a little confusing when you're coming at this fresh.  I've checked exclude from display.  We don't want to say the creature's ability next to the creature's name every single time.  We want to group it by that ability.  And so we don't want to show it right now.  But we are going to tell it to link to the taxonomy term so that when it does show up you can link through to the taxonomy page.  

And so back under our base view settings, we're going to go to format, and we're going to click the settings here under the main format, and this is where we have the option to start grouping things.  And so we can group it like content title.  That's not likely going to be useful very often.  You'd have to be doing something very specific for content title to be a good grouping.  We're going to group it on the taxonomy term name that we just added in.  

The last thing we're going to take a look at for the structure is we want to make sure that these things come in in a sane order.  Previously, they've been jumbled up.  The default sort criteria assumes that this is something like    something like a blog where you want to show the most recent content first, and that's not really what we're aiming for when it's more static content.  Static meaning we're putting this in once and for all.  This is part of the structure of the site now, not just    not just metadata on posts.  

So we're going to go ahead and remove the sort criteria and add our own.  The first thing we're going to look for is that taxonomy name.  And this is going to mean that once we see the groupings of the creature types, they're going to be in alphabetical order, so we look for a name, we grab the taxonomy term, and then we're going to also add the title so that underneath those headings, the creature names are going to be alphabetical as well.  We'll add and apply that.  

Now let's look at our preview.  This looks a lot better.  We have beasts, beings, nonbeings, and spirits.  That's all in alphabetical order.  And under each of these, they're in alphabetical order.  The other thing I want to show you, and this is a setting that's easy to Google.  I didn't throw it into the slide to complicate things.  You can tell views to show you what the underlying SQL query is.  So a SQL is a tool in your toolbox already.  Views is not behaving the way you expect it to be used.  This is a very common thing.  Views is definitely a learning curve part of Drupal.  

Sometimes having the SQL query there to tell it, show me the steps, how you got to where you are, is to good way to get Drupal and views to tell you what you're thinking.  If SQL is not in your toolbox, it can be a good way to ask for help.  So trying to get views help on, say, stack overflow, it can be more difficult, and you'd have a smaller group of people being able to help or understand what you're describing if you're just showing them screenshots of views, but sometimes that query can be helpful in getting help as well.  

And then because we're creating a page, I want to go ahead and just add a header here.  We're going to add a text area.  And we're just going to put down some convenient explanatory texts for what this page is about.  

And with that, we've created our view.  Our view also has a page that it lives on in the Drupal routing system.  So if we go into the site's configuration, go to the basic site settings and give it the URL of that new shiny view that we just created and save it, this is now our new home page and it's done.  All right?  Is that really everything?  

Obviously, there are a couple of other things that we touched.  There's an appendix to the slide deck.  I wanted to leave room for questions.  I don't want to    I don't want to run us out of time.  So I'm going to go ahead and leave this as something we'll go over in the presentation if there's time and interest.  But otherwise, there's a little bit more step by step information at the end.  

So we're just going to get and keep things moving for now.  I want to talk about some quick taxonomy design principles.  In some ways, I think this might be the most useful part of the topic, and I think the thing we might most come back to in the question and answer.  

I've got four comments for you.  Okay.  Comment number one.  Taxonomies blur the line between content and configuration, but they are content, not configuration.  Leaning in with a heavy one here.  This is one is a complicated thing to understand, but, you know, sometimes you're developing a site, and you're using tools other than just ad hocking the configuration and copying the database into production.  Like, no slate on that at all.  That is a great way to do a simple site.  That is often the best way to communicate with the clients.  But there are times when you've got a more complicated work flow and you're working with a team, and you need to have everything in source control, and that means you're using deployment tools.  Like configuration manager.  Okay?  

And sometimes this gets really blurry where you've got a taxonomy that actually builds out the structure of your site and builds out how your pages link together.  Well, you're going to have to have another solution for that, okay?  Sometimes you've got to do things to fill in the gaps.  You know, if you're using configuration manager or features, things I've used before include install hooks and custom modules that, you know, allow you to set up the vocabulary and prepopulate the terms.  

Another thing that can be helpful is capturing the terms as, you know, variables in the system under a unique and repeatable name so you can do all your program.  If you have to address them programmatically, you can go against a variable name instead of hoping that your system and the staging server and your friend's system all used the same term ideas.  

So if it's got an ID on it, it's content more than structure.  And more than configuration.  Okay.  

The next thing is it means that taxonomy terms are not static.  They're going to need careful planning and maintenance in order to keep them online.  It's a garden that needs to be weeded.  It needs to be tended.  And oftentimes, when you've got more stakeholders in there, you've got to be careful to make sure that people don't add things that don't belong there or take away something that someone was relying on.  

I mean, there's a certain philosophy about this, too.  The third bullet point.  If you have separate teams developing the site and its content, this is a really crucial point of collaboration.  You need to make sure the content developers understand the taxonomy system and they've on the same page.  There are certain philosophies about what you want to include and what you want to exclude, and you want to make sure that you're not butting heads over there, and the content team that you're going to hand the site off to understands how to drive it.  

Comment number two.  As mentioned before, I think twice before using hierarchical taxonomies, and think even harder about using more than one level of nesting.  

So if the views discussion was a lot to take in, getting views to work with hierarchical taxonomies is a lot more complicated.  Not terribly pleasant.  Ask yourself if a representation of the hierarchy actually makes things easier for the user or you just think it's necessary.  If it makes things easier, and it's really helpful to the user and if you think it's worth it, go for it.  It's there for a reason.  Just don't assume.  

Comment number three.  This is one of the biggest philosophical arguments you can have about taxonomy.  Don't make your categorization too broad or too narrow.  You've got to find the Goldilocks zone.  The conflict between the universal and the particular goes back to Socrates.  Probably further.  We don't need to overcredit dead white men.  Greek is white    well, western.  

Anyway, cast your net too wide and you're going to connect things that are too dissimilar to each other.  And if you're too familiar and meticulous in all your distinctions, you might miss meaningful connection.  These are all about making connections.  These are all about joining ideas together.  And grouping things that are helpful.  Just focus on what's helpful, okay?  

So so.  Examples from this talk.  We used uses fire instead of breathes fire.  In this example, I think that fire is what's important.  Whatever a blast ended skrewt does with fire, it isn't breathing it.  So we broadened the feature to make it more useful.  If you're wondering do I need to wear fire proof clothing, you're not really asking which end of the creature does the fire come out of.  All right?  

Spirit versus non being.  Yeah, this is one of those things that I think could be very controversial to fans and purists.  But, I thought it might be worth mentioning here.  This argument is exactly the sort of taxonomy argument you would have.  

Non beings are things like dementors or boggarts that are amortal and borne out of human emotions.  I think that's enough to set them apart from things like ghosts that maybe we can give them their own bucket, because there's something slightly different going on with them.  You know, they're not exactly a banshee, they're not exactly a ghost.  We create another division to be more precise.  Maybe this is a helpful division, maybe it isn't.  But that's the sort of thing that I think might be an example of creating an extra category because that extra category makes a meaningful distinction.  

And my fourth comment is keep your users in mind and fight for simplicity.  Okay?  

When there's a conflict between the precision that we feel is necessary and the simplicity that will make the site easier to use for users, we need to let go.  I mean, I can say I work with librarians.  Librarians are very precise.  They're very passionate about their precision.  And sometimes, that causes arguments.  Okay?  

Sometimes we have to advocate for simplicity against clients and against stakeholders.  Because it's what's best for the user.  And the reason    the big picture for this is that a simple site breeds engagement.  Now, maybe there are ways to bring some of the extra precision in that are at a deeper level in the long tail of user engagement, some people who are really, really hooked can find what they need.  

But we want to make the cost of entry, the cost of starting engaging with your site as low as possible.  Okay?  

So, the conclusion.  Thank you for joining me in this talk on the subtle science and exact art of taxonomies.  Use them well and you will be able to bottle organization, brew user interaction, and even put a stopper in your page's bounce rate.  Thank you.  

>> DWAYNE McDANIEL:  All right.  I'm going to unmute everybody.  A huge round of applause.  

[Applause] 

>> DWAYNE McDANIEL:  All right.  I'm going to mute everybody again.  That would get a little chaotic.  If you can pull up the chat... you can see there's a lot of good comments in there.  A lot of it about Harry Potter.  Great presentation.  If anybody would like to use a question out loud, go ahead and use that raise your hand function in the participants menu.  

Wouldn't it be fair to suggest taxonomy as meta content more than just content?  

>> TIMOTHY YODER:  Yeah.  I mean, I agree that it's meta content.  It's one of those hard to define distinctions.  I mean, I was wanting to focus on it mostly in terms of can you rely on this existing if you're using it as part of your structure in sight development.  If you're working with a configuration manager, you're working with features and you're expecting your site to deploy out with it, then you might have a bad realization when you find that you've blown away your database and tried to rebuild the site and all that content you were relying on isn't there.  

It's a lot like users aren't exactly content, but if you    you can't build out a site from lower principles without    and include users without doing something else to accommodate them.  Yeah, it's a fair distinction.  

>> DWAYNE McDANIEL:  All right.  Forgot to mention that is a question from Daniel Venditelli.  

There was one other one here.  Are you Slytherin?  

>> TIMOTHY YODER:  I think of myself more as Ravenclaw, although I really liked McGonagall a lot and I also really like Alan Rickman.  

>> DWAYNE McDANIEL:  Also from Daniel.  You mentioned the TID could vary between two working groups.  Seems like a potential huge headache if they differ.  

>> TIMOTHY YODER:  I mean, I can only    this is one that I would love to, like, open up to other people, especially people who have more experience in Drupal 8 itself.  I mean, I saw Bec White had a good comment on the UID having additional functions.  For the simplicity, I didn't go into that.  

But it is an important distinction.  The way we've worked in the past    and I have to admit, I mostly work on a Drupal 7 site, is to aside TIDs to a system variable, and then always working    you know, if I've got to do any programmatic selection, I'm working off of the TID.  

Now, various views exports, that can get really, really difficult.  If you're telling a view to be contextually bound to a specific term ID, you might have to do some real magic footwork to get that to work in a rebuild.  

>> DWAYNE McDANIEL:  Right on.  A lot of comments in there.  I guess chats are good for those kind of comments.  Does anyone else have any other questions at this point?  Or anything you'd like to comment on?  Feel free to raise your hand if you want to shout it out loud.  

So you would be faced with matching new UIDs and repopulating in the database?  I guess that's a question to Bec White.  

>> TIMOTHY YODER:  Yeah.  Oh, she had the suggestion.  You're right.  She did.  

>> DWAYNE McDANIEL:  Actually, if you wouldn't mind me unmuting you, Bec.  If you care to talk out loud.  

>> BEC WHITE:  Yeah.  I mean, if the issue is like creating taxonomy terms during development and having development content, or something like that, you know, I don't think you could really solve it with UIDs.  I think that's more for just making sure content is aligned across different sources.  

But it doesn't help at all with views or with entity references or anything like that.  

>> DWAYNE McDANIEL:  Thanks for that perspective.  

>> TIMOTHY YODER:  Thank you.  

>> DWAYNE McDANIEL:  All right.  Put you back on mute.  Raise your hand if you want to come back off, Bec.  We got a question from Ralf.  At what point get the number of terms and/or the layers of hierarchy get in the way of site performance?  

>> TIMOTHY YODER:  I'm also very open to other people talking to this.  Just assigning them isn't going to do anything harmful.  You can do an awful lot of creating the taxonomy.  Your real pinch points come when you try to visualize it.  Like, I always tend to go back to SQL language.  Sorry, if that's not helpful.  But if you have to crawl your way down the hierarchical taxonomy, that's the equivalent to adding a bunch of joints to your query and it's also worth knowing that, you know, the query that you get in the diagnostic mode is not exactly the whole story.  It's definitely telling you what it's doing to visualize, but there's even more overhead to what you're seeing.  So, if you're doing something that's going to require you to crawl down a bunch of different levels, that's where your performance hits are going to start stacking up really fast no matter how many things are in the actual view.  

The other thing, though, there are ways to get around it.  If it works, you can actually have people drill through so that you say, you know, okay, here's the list of top level terms.  I click on one of them, and now I'm going to contextually filter on the next level terms that link    that are children of what we just linked to and the top level term, it's going to pull it out of the context.  

Contextual terms, I'm sorry, they are in the appendix to the slide deck.  But we haven't gone over them.  There are very important concepts, especially when it comes to making hierarchical views.  

So, like an example of this would be    one site I worked on at one point had a sort of directory structure, where it had a whole bunch of different categories that you would want to drill through.  And, you know, for the sake of simplicity, I allowed that one to be nested three deep, maybe just two deep.  No, three deep.  I didn't show any content on the first level.  On the second level, I started showing content.  But, you know, I might have had to gate that content on the second level.  

And on the third level, you're doing much better.  I hope that's helpful.  

>> DWAYNE McDANIEL:  Cool.  Some conversations still going over in the chat.  Good conversation.  There's a question in there, looks like.  I think that's a conversation between    oh, here we go.  Tim, so beyond user simplicity, is it maybe better to view taxonomies as flatter list of images    I'm sorry, flatter list of tags?  That makes more sense.  

>> TIMOTHY YODER:  Yeah, I mean, I think depending on your taxonomy, there are times where the structure is valuable.  Lists of tags.  I think if you can get away with it, I think it's often the easier way to go about it.  

But sometimes, if you've got an awful lot of content that you're trying to curate, it might be helpful to do a hierarchy where first thing you're looking at is just a list of top level categories, and then you start breaking out the content once you've selected that.  It really comes down to what's your taxonomy doing.  

>> DWAYNE McDANIEL:  All right.  Any other thoughts or questions here at the end?  Well, I want to say, again, thank you very, very much for giving this presentation.  It was awesome.  I am going to go ahead and stop the recording now.  So, thanks again.  

>> TIMOTHY YODER:  Thank you.