 Hello, everyone. I hope you all enjoyed lunch. Today, we'll be talking through the work we did for the Office of the United Nations High Commissioner for Human Rights, OHCHR, also known as the UN Human Rights Office. OHCHR is the United Nations organization that focuses on promoting and protecting human rights, assisting governance through field presence, helping to empower people, and giving human rights perspective to other UN programs. This project involved a comprehensive taxonomy, UX, and visual redesign work to completely overhaul and relaunch a new Drupal-based website to better support the need of users, both external audiences, internal content creators, and managers. This approach allows people to find what they need, like the proverbial needle in a haystack. Now, this is an updated version of a talk we gave for Drupal Europe last year. We now have 100% more lessons learned to share with you today. We'll also talk about a number of challenges that we faced in more detail. My name's Michelle Ann Jenkins. I'm the taxonomist on this project. And my work was both developing the taxonomy and providing input into how taxonomy could be leveraged by UX and information architecture. I also helped oversee the content re-tagging and provided input into other parts of the migration. I'm also not this tall. I'm standing on a box. So hopefully I won't fall over mainstream, but I just want to be transparent about my height. And I'm Sam Zimmerman. I led the client partnership for Blue State. And so I worked closely throughout the two and a half years that we've been working on this project with OHCHR, with the client team, and also forging our relationships with Dovcott and Accelerant. And a member of our team who couldn't be here today is Suzata Bharadharajan. She is in Chennai, India. And so Suzata was the business analyst on the project from the Accelerant team. And so some of the insights we'll be talking through today were originally written by her. So as an overview, we are going to share a background about the scale and the complexity of this migration project, how a holistic taxonomy helped us address these challenges, and what the process was so that we can offer you sort of a practical lens for how you can apply taxonomy work in maybe similar projects that you might be undertaking. And hopefully we'll also have some time to answer some questions. So the challenge, we'll start with an overview. OHCHR, their site serves a variety of audiences. A few of them are seen here. This ranges from the general mass audience, public users, like high school students who may be researching a report, or journalists with a very light interest, trying to sort of uncover some work that they're writing about, to audiences with much more specific interests, academics doing research, government officials setting policy, refugees themselves trying to figure out their way in the world, and migrants, and then really specific technical work for lawyers in the human rights field. So these are sort of power users. So they're coming to the site to actually interact with OHCHR and perform their important work. When OHCHR came to us, their site had last been updated in 2013 when it had been migrated to SharePoint. Eek. And the interface design seen here dated even earlier than that. So they had just done a straight move on to SharePoint with an old design. And these pages were packed with many sort of visually non-hierarchical links that were all manually authored in the system. So here you have a taste of the old homepage. It's lots of stacks of boxy links. And right up front, you have to start doing a lot of work as a user to figure out the next step on your journey into this site. And not only are there many types of users coming through the site, it's also a site that needs to organize hundreds of topics across every country in the world and in many languages. So OHCHR publishes in six official UN languages, but they provide documents in up to 500 languages through this site. Content is related to multiple geo locations across almost 200 territories and countries. And so you can see here how content related to the country Columbia was presented in the legacy site, all of which was authored again manually. They had been living with this site for many years and were able to accomplish their day-to-day work, but it was impossible to consider making any improvements or changes. So they were sort of stuck running the business as it was. And they couldn't move to responsive design or accessible design or anything that we would consider a modern standard in that platform. So in 2018, they embarked on this migration project which started with a content planning phase, which Michelle will speak to. And in 2020, they began to work with Blue State and Accelerant on the UX design and migration to Drupal, which launched last month. So there's a happy ending to this story. Spoiler. And now I'll pass it to Michelle. Great. So as you can see from those samples, they faced a myriad of challenges in visual design, usability, accessibility, managing their site. Today we're gonna focus on two key challenges around findability and discoverability. So findability is an issue not only for the frustration of users just trying to get at the information they're looking for, but it can natively impact the credibility of an organization. If you can't find things and they're not organized and time hasn't been taken to deliver up the information in a useful and intuitive way, it then leads people to wonder what thought was put into the information itself, what organization I'm looking at. It is one of the things that we intuitively use to judge the credibility of a website and kind of separate information and disinformation. So it's not just about I can't find something, it's about the organization and its brand and its ability to do its job. Findability is also critical for internal content creators and managers. If you don't know what you already have, you end up with redundancies, duplicate effort, or gaps in your coverage. And when you have a site of this size, there's no easy way, as you saw from that Columbia page, to just take a peek and see what you already had. Now discoverability on the other hand is more about offering up a range of products and content and kind of showing the breadth and depth of the organization's work. So even if I'm going there, maybe to find a press release, discoverability will lead me to understand here's some of the other work they're doing, here's some areas of research, here's something else that I didn't even know that I needed, because the website semantically understood what to offer up based on what pages I did go to. So some summaries of the challenges. First off, the sheer volume of content. We're talking about over 20,000 web pages and over 30,000 other assets ranging from PDFs to spreadsheets to media assets. There was no single content audit. And if you've ever worked with SharePoint, you know there's not an easy way to ask for a report. So what we're all very used to with Drupal and Views was not possible. There were other systems in play as well, and frankly it was a real challenge to get a handle on the scope of content and even what existed. Secondly, OHCHR has amazingly complex internal workings. I had to learn a lot about international legal mechanisms and in fact a lot of time figuring out what is a mechanism? And then you have your organizational workflows. Again, very specialized, very particular to this UN organization. And then their need to respond to current events and crises very quickly. All of that produces a ton of different content at different parts of the workflow. And like many large organizations, OHCHR is extremely siloed. People have no idea what other people are doing. There's no one with an overview of the beginning to end processes. People are very focused on, it shows up in my inbox, I do my thing, and it moves on. So this leads to very distributed ownership. There was no holistic governance about what went on to the website or why, and disjointed workflows. Finally, each platform, or additionally, each platform or content area in these silos had solved their own problems their own way. So you might have something as simple as we'll see as a list of countries that has represented seven different ways on seven different parts of the website. Everyone was solving the problem for themselves without, again, that overall governance or vision. And there was no way to aggregate content from different sources together. So if you had a news article on Columbia and you had a report on Columbia, you might not be able to connect to those. The current architecture required extensive manual effort. So any sort of improvement, like here's a better way to present news or a better way to have our stories had to be manually repeated on hundreds of pages. And this made them very reluctant to do any sort of changes because there was just too much overhead. It wasn't a matter of updating a template or changing a field display. It was literally people having to edit pages over and over again. They needed to automate their workflows and have a solution that could scale and grow dynamically so that they could make iterative improvements over time. Finally, user feedback and research revealed issues, not just with findability, but the site's credibility and their ability to engage and deliver. People would come to the site and very quickly give up and people were not finding it a useful resource or a useful place to say bookmark and come to it. I think they ended up having a lot of phone calls or a lot of emails or people kind of working around the website, a lot of sending somebody a link because they couldn't find it. And our solution was to have a holistic taxonomy approach. So you can kind of think of it as taxonomy first design. Let's take a step back. It's been great being here at DrupalCon this year because you guys say taxonomy all the time and every time my ears perk up and I go, oh, they said Drupal, oh, wait, they said taxonomy. Who are they? But taxonomy in Drupal is a functionality. It's a place you can go and make things happen. It does not always mean that is used for best practices and taxonomy development and design. It's a place you go and type some words. You put your tags in there. There's a whole field of taxonomy analysis for business and for documentation and for digital asset management. Not the one you learned in school about fish and cats and birds and how they all fit together, but business taxonomy. And the reason we need to have taxonomy and business is because we have problems like this. Has anyone figured out these four separate concepts? What label describes all them? Mercury, good, good, good, good. So we have a word like mercury. Human language is super messy. When I say mercury, you might think of these four different things. It gets even worse when we hand this over to a machine and we say, give me everything that's mercury and they're like, here's a car. Here's some dangerous fluids. The flip side of that is this guy. It is a little thing that goes under your hot pan and these are taken from an e-commerce site search logs. These were all the different ways people typed letters, labels in to try and buy one of those little thingies. I find this tends to be quite regional. Some places I go, everyone says trivet and other places everybody says pot pan. I'd never heard trivet for that. I always think of it as like a little thing that goes in a barbecue. Anyway, the diversity of terminology presents terrible problems for machines and humans. Taxonomy provides a solution in two ways. The first off is what we call control. So taxonomy is a kind of controlled vocabulary. That's what distinguishes it from free keywords or folks know me is that there's an authority deciding to control the label. We have one label that's a preferred or default label for a concept. We decide what it means in that context and how it can be used. We then apply structure to that, usually in a hierarchy that's a semantic relationship between broader and narrower subjects. There's other types of connections that we'll talk about too, but this is the basic one that gives taxonomy a lot of its power. Because if we think back to our mercury, that car mercury is gonna have a different relationship to subjects than the God mercury will. Here we see a flock of taxonomists in their natural habitat, which is sticking post-it notes into little clusters. We've had to migrate a lot to things like mirror boards and online tools because of COVID. So I don't have my usual post-it note paper cuts. But it's interesting to see that this is a field that's really developed over the last 10 or 20 years. A lot of people come from a librarian background. So you come from archivists or collection development, those traditional library skills. But you also see people coming out of engineering where they're looking at semantic relationships, ontologies, data lakes, knowledge graphs, and recognizing the need for taxonomy. Content strategy obviously plays into taxonomy as well. Personally, I come from a couple of these. I was a programmer working mostly on Drupal and I went back to school and got my masters in library science to focus on this very particular problem that I found so juicy. All right, turning back to our work for OHCHR. So we needed this holistic approach. I came in very early in the project and I knew that taxonomy was gonna be pivotal to drive all the business logic that they needed to automate their workflows and make their content more findable. So we did this by attempting to maximize collaboration. We had our taxonomy, our UX, our technology, the content owners, the stakeholders, the migration folks and we had to get in line and we had to be transparent and we had to talk together as much as possible. Due to the size and complexity of the existing site, we had a ton of analysis. It kept going through the majority of the project, discovering new areas of content, re-understanding what content was and how it changed through its workflow and it took a ton of work to get everybody on the same page so that I could say, I know a little bit about it, you know a little bit from this other side and you know a bit from the other side, how do we put this all together? That analysis went into the initial taxonomy development. So we did the first pass on the taxonomy before we even had web development and visual design and UX brought in. So we started working in spreadsheets, trying to capture what are the concepts we see here, how do we need to describe the content, what are the hooks we need into this? It can be a chicken and an egg with taxonomy, what is the right time to bring in it into a project? You need it both early on but then you're always gonna end up doing refinements and adjust fit to purpose once your technology is in place. And then that taxonomy provided a lot of the hooks that the UX designers needed for the overall information architecture. So how are we going to set up the views, what fields are needed by content types? And then sometimes we found the need for additional taxonomy terms or additional metadata on our taxonomy terms. We need a short label here. We need to be able to connect these two things. We need a view that can do this. That would feedback to taxonomy or the taxonomy itself would suggest new things that could be done like connecting committees with subjects or countries. And then we say, hey, let's build something around this since we have this in the taxonomy. The development planning phase was a huge chunk of the work. It was really figuring out how to make everything work together. A lot of this took place in shared Google spreadsheet. So we had sort of a living document or many, many living documents to try and align all these different areas of work. Once all the plumbing was in place, then the heavy lifting to build out the site structure happened, assembling content types and views, putting the pages together. And at the same time, we were re-tagging those 50,000 content items so that they would be ready to import into the new system. So this covers our recommended approach. This is what we were trying to do. I think it was a very good idea and we all bought into it wholeheartedly. It is not entirely how it played out. So we continued to find new rabbit holes constantly. You would ask a little question and tease a little thing and then you're like, wait, there's this whole sweater that's unraveled in front of me. We had to adjust our understanding of the content. We had a super hard time getting access to subject matter experts. These are people working day to day on human rights crises around the world. And I'm saying, could you explain to me what we mean about this word in this context? No one had time for us. And it was really hard to get someone to be the owner of things. So who decides, how do we refer to Palestine? What's the label in the filter? Can we just say Palestine? Can we just say Kosovo? Or does there always have to be a footnote if we say Kosovo? And a lot of times these questions got handed around and no one wanted to make a call on it. Having multiple agencies working together, each of us, we had different processes, different viewpoints at different timelines. And sometimes we just had to move forward even if we knew we didn't have it right because you only have the designer for this long or this is how much is in this budget for this part of the project, just keep going. And that's sort of a practical concern that I imagine half the people in this room work at agencies and the other half maybe have worked with agencies and in this case we had several agencies coordinated together with the client team that was very overextended and strapped. And a overarching concept was that the contracts had a finite duration and the project had to be finished by a certain date and therefore taking more time to figure out these shifting and evolving requirements in the front which would have been a good idea didn't match up with keeping that fixed date to launch the site which procurement was insisting on. So at a certain point, we had to have the starting gun on the UX UI work like we couldn't delay working on that any longer and so we had to take our best shot based on what we thought was settled knowledge while some of the taxonomy requirements were still in flight. And of course because we did that we had to add sprints to go back in revised designs that we thought were settled in earlier sprints when we found out that there were some new requirements that had to be accommodated. And this sort of went down the line when we did our upfront technical planning there was a lot of overly optimistic assumptions that were baked in that had to be reinvestigated once the work actually was underway. And then this is somewhat unavoidable in a site that is as vast and as specialized as this one where it is impossible for our project teams to become anywhere near as expert in this content as the client teams. And so as we're showing back our work the clients are always spotting things that are wrong. Oh, this is the wrong, this solution won't work you've left this out. And it's difficult for us to see that before showing it to them because we just don't know this content as well as they do and what it's supposed to do in the new site as well as they do. And it's just a learning curve we're never gonna get over. So as a result there's a lot of sort of iteration in the migration process where we made a plan, we tried to migrate some content and transform it. We surfaced all of these mistakes. We went back, we revised the scripts. We re-imported the content and that was a rinse-repeat process that went on for months. And finally we arrived at a mostly acceptable solution that included a lot more manual work than was desirable for any of the parties but really at that point it was just this is the way that we can get this thing done. So that I think is probably, we'll come back to this in takeaways but something that is a important concept is that you're never going to get a perfect script to automate this kind of thing. And so you really have to focus on pragmatic critical path ideas. So now we'll talk in a little more detail about the work that went into each work stream starting with the taxonomy. So the first step in a taxonomy development project after that initial analysis or attempt at getting a handle on the scope of content, the technology in play, the organization's goals, the user needs as much as you know about them is what we call a taxonomy framework. This is the blueprint for the taxonomy that you're going to build. It is a combination of best practices. There's an ANSI standard that we follow that is really dense and dry and we'll put anyone who's not deeply invested in library science to sleep but you're able to use that as your foundation and then that's the kind of science part and the art is customizing that to the practicalities of the situation. The taxonomy framework can be 20 or 30 pages long, mostly only the taxonomous cares about it but it guides us through the development and then it becomes the Bible to manage and maintain that taxonomy going forward so that you have consistency in everything from your term form. People notice if you're using title case one place, sentence case another place. Are you using commonwealth spelling, English spelling, what are you doing with hyphens? When are you allowed to use parentheses or a slash? What form of verb do you prefer? All of these things, how much pre-coordination or compound terms are you gonna have in there and then laying out everything this taxonomy is supposed to do. Is it gonna be visible to end users or is it just plumbing? Are you gonna have faceted filtering in your search? Are you going to have people clicking on the tags and seeing a view that itemizes everything? All of those impact the kind of taxonomy you are going to develop. Once you have that framework, you start going fishing for concepts. What are the ideas that you need to capture? And here we can see that there was an idea around weapons, guns, firearm and later we needed to break that down and say, do we need more than one concept? Are these the same things? Is a gun and a firearm the same thing in this context? How much content is there? Do we need to get into more detail? What is the default label and what will be the supporting synonyms? But first we really say, look for those concepts and have a giant candidate term list where you start to aggregate things together. Then you get drill down and start defining them and labeling them and figuring out which content types need to use what. In most cases, I would say that organizations have some way of organizing their content. It might be folder structure, it might be file naming conventions, gotta help you. It might be existing taxonomies, filtering, website navigation and when they've developed independently, there are people writing out some strings that's gonna be differences. It might be simple differences like over here it's a compound term, we have apples and oranges and over here we have oranges and apples and over here we have Fuji and Gala and you have to decide how to pull those together. In this case it's very weighted. It's super important that the UN says these things right. But as we can see, there was no shared definition of what a country was. They had a list of countries and some cases they had regions and some cases they had contested territories and some cases they excluded the small island nations. It had to be reconciled and it required so many meetings and so much trying to get people to say yes I'm the person who can make this decision for you because everybody's like, once we have our concepts, once we have our labels then we start to work on the structure. So when we have a parent-child relationship it means that tagging a piece of content doesn't just apply that label, it connects it to entire network of meaning and you can do things like roll up into broader topics and say just give me everything that's about civil and political rights and I don't really care about more granularity but a researcher over in another area might really care about the difference between privacy and surveillance, which was an open question. Beyond the parent-child relationships you can also have other relationships. These cut across the hierarchy and can often cut across different facets or different vocabularies. These can be used to surface related content, broaden searches, make suggestions about other areas of content. If you wanna say here's a news item, show related content that could be directly related or something tagged with any related terms you just get a broader pool of information. And one of my favorite things about working with Drupal as a taxonomist is that there's just an out-of-the-box ability to support named relationships. You can create a relationship between two terms and call it whatever you want. You're basically getting into proto-ontology with this, that's the real difference between a taxonomy at, well, there's a lot of difference, it's a whole number of sessions, but one of the key differences is if you overload your taxonomy with enough named relationships you basically have a mini ontology. This gets really cool with your business logic, you start getting into a little bit of like traversing knowledge graphs and you can ask really complex queries of your information in a way that opens up a whole world of dynamic content. So here we see a relationship between a committee and this work. This turned out to be really cool, like we can tell you what are all the different organizational entities that work on a country. They weren't able to do that before. Who are all the different things that are working on a subject or roll them all up to a broader level. Once the taxonomy is fully developed and we have all these additional properties and we've had somebody say, yes, these are okay labels and here's the relationships, it's ready to important to Drupal. Generally speaking, I do all of my initial work in spreadsheets. Increasingly, there are more accessible taxonomy management tools. A lot of the heavy hitters, there's Pool Party and Synaptica. The overhead in setting them up is enormous and so generally they come in later in the project, but we're starting to see a little more kind of quick and dirty sign up for it and have instant access to a pretty basic taxonomy management tool. Once it's in Drupal, we end up continually making refinements there as well. Now that the site is launched, it's all about the governance. I think taxonomy is a puppy. It's not getting the puppy at the beginning, it's the next 15 years of vet appointments and walking them and cleaning them up after them. You need to have governance in place because there will be new subjects or there will be subjects that need to be retired or there will be label changes, especially if you're dealing with social issues or technology. You have to know your processes, who gets to say okay, who gets called in to answer important questions and making sure that you have really clear documented taxonomy governance frameworks is really the difference between succeeding or not with a taxonomy. All right, so now you've all had a crash course in the taxonomy world and what we did for OHCHR and I'll talk a bit about how then this played out in the UX design and the architecture of Drupal. So for OHCHR, we designed templates and components with multiple touchpoints to make these taxonomies come to life and reward end users and CMS users alike. And so going back to our before state, here's the example we gave of the country detail page for Columbia that has too many links that are manually curated in a SharePoint and presented in this visually differentiated way. When we redesigned this page, which you see here, we designed it completely around the new taxonomies and so the information hierarchy is clarified visually which improves the experience for navigating as an end user but the links are populated dynamically which really eases the burden for the editors that are responsible for these pages. So this page is tagged with geolocation and then all of the components that surface items in sections of the page pull from that geolocation and the variations depending on the content types and the categories in our metadata scheme. So now all content sort of automatically finds an appropriate place into these landing pages based on this tagging and it's really specific to OHCHR format. So in this scroll here we have news and statements and stories and reports and those are like pretty common concepts across a lot of many organizations but then we have special procedures and treaty bodies and so again this is like something which is tailored specifically around the needs of OHCHR as a UN agency. The topics pages presented a similar challenge. We had over 150 of these pages for topics such as freedom of expression. So here we have the legacy version and here we have the redesign version. It's all tagged with subjects that are related to freedom of expression as a topic and then it goes and it matches the content that populates from components for different types of content categories. So just scrolling down the page here we have the call for input content category and a little bit lower we have reports and you can see there's little clusters of information like date and author and type of report that travels with the headline and we have stories which has other things like the published date and hero image and so forth. So many other content types that can be pulled into these pages and wherever your entry point is into the site so maybe you're hitting one of these pages directly from a Google search. The site design leverages the taxonomy to give you an assortment of next related content that you might want to travel onto from any particular page. So here at the bottom of this story we've got three types of related content. There's a set of specific links which were referenced in the body copy that we pulled together at the bottom again. There are a set of topic tags and then there's a curated set of related stories at the bottom and so if you click on a topic tag then you go to a pre-filtered tag for hate speech for example and you quickly get results that are related to hate speech. A little journey there. And then what does this look like on the back end for editors. So for a site editor previously was asked to maintain all of this in SharePoint manually setting up these relationships is now a task of composing the page, selecting from components that have been pre-built to pull in this information by tag automatically. So in this example we have the country of Columbia. The editor can select from a range of components and so we have our typical Drupal drag and drop up and down the stack interface here. This editor selected the component for news and statements and then underneath that a sub-component for latest statements and messages and then dynamic views are generated based on the taxonomy term combinations. So when new content about Columbia is created and then the author tags it with latest statements and messages it gets pulled into this page automatically. That's kind of like a duh, why wouldn't a website do that but that's not what they had before and that plumbing behind the scenes didn't exist and so as part of our migration of that source content we also had to add all of this tagging in that process. So that's the complexity here. As you take 65,000 pages of raw unstructured content and then you layer this structure on it and all of the work to enhance it with that tagging as well as create these new page layouts and create these sort of navigation experiences that you want to be new and up to modern standards. So that's the complexity here. The project to sort out how to use the taxonomy in the architecture and then create these user experiences took about eight months to plan, test and debug and that got us to the point that we could begin to do migrations and so then we entered a four month phase of attempting to migrate, finding errors, doing manual cleanup and getting it to the point that we think we have the right site with the right content but now we have a site that has so many relationships that you can go down, do these automated processes. Massive database turns out it's not very performant and so we spent another two months figuring out how to make acceptable load speed for this new fancy site which had this system of taxonomy that didn't exist before. So all of which is say we finally got there and now OHHR.org is live and you can go visit it and see for yourself what kinds of things the taxonomy enables. So now that the site is launched unfortunately the work is not over because as we all know it's never over, it's an ongoing process. They're going to find new issues, they're going to get more user research, they're going to have their analytics, new crises, new issues and new places are gonna emerge and they will have to continually manage and actively manage the taxonomy and any implications for the user experience and the technology that needs to support that. So that tension between we have a new requirement so we need more taxonomy and hey some new things have emerged in the taxonomy and they generate new requirements means that you're constantly actively engaged with the development efforts. And OHHR really has a responsibility to allocate the resources needed to govern the taxonomy and the content, to train people and to make sure that they're checking the quality of the work that goes into it to make sure this is all being properly used and governed over time. So we learned a few things while we were doing this. First off you can't just hand things off in a traditional waterfall and I think this was the client's idea at the beginning was they hire a content analyst, they hire a taxonomist, we'll hand a spreadsheet to the next person, who hands it to the next person and then at the end a beautiful site emerges. There needs to be a lot more integration and backtracking and a non-linear experience. Like beyond iterative is just everyone needs to be on the same page and have a level understanding before moving on to the next part. With working with multiple agencies there has to be clear ownership. We had a lot of sous chefs and not as a single point of contact chef who was telling us what sauces go on, what dish and that ended up being that people had to step up into roles that they weren't necessarily meant for or reusing resources in different ways to fill gaps that should have been defined early on as that single point of contact. And then when one agency moves on to their next project there has to be a clear handoff and documentation so that the client is fully informed of what was done, what it means and what its connection is to the rest of the work. So ideally we do want in the upfront planning of the content strategy to have the taxonomists, the UX designers and technical architects collaborate so that they can see how those taxonomy plans will have implications for all of the other work. However, the structure of the relationships and the engagements of all these parties and the relationship with the client may not be set up well to support that. And so if that's the case, it would be a really good thing to flag that as a risk and to try to find solutions to facilitate that type of collaboration upfront because that extra time that you spend, in our diagram of the winding road to get to the final taxonomy requirements, if you don't spend the time upfront to really make all of your plans fit with that, those requirements, then you're going to end up spending the time on the back end when it's much more stressful and you're failing to deliver and their managers, the client's managers are looking over their shoulder and people are trying to figure out how we're gonna get this to launch. So find a way to structure the relationships and the contracts with all these parties so that you can have this planning collaboration at the appropriate pace that it needs to go. We don't wanna wait till the new CMS is built and the contract migrated to, at that point assess whether we got it right. Most likely you'll find that you did not. So we think it's probably a good idea to use intermediate tools like gather content early in the process so all teams can see this stuff in a tangible form. If you have it in spreadsheets and different wireframes and so forth, everyone is perceiving it from their own perspective but they're not really seeing it the whole picture or in a way that everyone can commonly agree on yes, we've got it right and we all understand it. I think that was a pitfall of this particular project is everyone not having a common place to see it in action before the software we developed in Drupal was developed. So that's going forward and next time I do this kind of work I'm gonna look to use those kinds of tools to really sort of align people earlier on and do some experiments. And then lastly, you're never going to come up with a perfect script to automate these migrations. You really need to identify the critical path of the most important things to automate and make pragmatic choices around where to invest manual effort because ultimately you are going to do some manual effort and that should be something that you are prepared to take on upfront and you are staffed appropriately to do and it's part of your project plan. And as well, there's going to be lots and lots of QA and some trial and error and make sure that that's not overly optimistically planned for as well. And with that, we have some resources. We will post this deck to the session page on DrupalCon site. And so you won't have to type these things in yourself. You can pull it off the deck if you go there to grab it in a couple of days. And happy to take questions. Yeah, yeah. Well, at the moment I show them the OHCHR website. That's my new favorite to show people. But there's plenty of examples where people use taxonomy every day. So e-commerce lends itself very well if I need to explain what a multifaceted taxonomy is. I'm like, you're looking for a T-shirt. It's red, it's medium, it's long sleeve. You want to be able to have the intersection of those things. I use a lot of analogies about fruit stands, current websites that are examples. I have a deck I have that just has cuts outs of like, these are taxonomy in real life in action right now. But yes, every time I do a project, I start with the assumption that nobody knows what I do or why I'm here. So anytime I've thought otherwise, I've had to backtrack. I use the mercury and the trivet in a lot of them. But yeah, people, even if you're using Drupal, and like I said, it says taxonomy, doesn't mean there's an understanding of that. And the possibilities of what taxonomy can do. So there's a lot of educating in those initial analysis meetings for sure. Yes. Yeah, yeah, I'm doing a taxonomy boot camp in November. I'm doing a presentation on proof of concepts. So proof of concepts are a great way to do that. Or if you can do a quick mock up in Azure or something. And really the carrot is you don't have to cut and paste stupid links into a list anymore. And you can free somebody up to do that. That tends to be a big carrot. Analytics and reporting where I say, hey, you can see all the things people are doing across all of your sites in a really easy way and see what content's doing well and what audiences. It's generally showing the use cases, showing current examples, doing a mock up and identifying what are their pain points and trying to connect to that. But I do also try and balance that by scaring people on how much work it is because it's a lot of work. So I've found that the core team that we design or that we gather to do the initial taxonomy development, it often works best to figure out who that should be and then they transition into the governance structure. And it really depends on the organization. If we're working with IMF, there's a 30 page service agreement governance framework. If I'm working with a fun little nonprofit, we have a three slide slide deck. So it depends on the complexity of the place. I do try and find if there's a librarian in the organization. That's a good point or someone in records management, generally or knowledge management is another area but it needs to be a cross functional team with an owner and executive buy-in and then hooks into the right subject matter experts. But yeah, it is really a challenge to get people to step up. I'll let you do some calling. In the middle in the back? Yeah, thank you. There were a lot of use of blocks. We wanted to have a very component based design and we really didn't have a sense of the scale of the database and that some of the queries were just very inefficient because they looked very broadly across millions of records and all of which was planned with the idea of sort of completeness and like going down all the trails that you could but when we actually saw it in action, it wasn't very performant and we had to analyze where those bottlenecks were. We also had some issues with the infrastructure being not provisioned in a very robust way and having to go to their IT and demand more. But all of that was a trial and error process. Over here? Not well. And not without a lot of like complaints and pain by the editors that had to keep the current SharePoint site alive while we almost had the new site ready to launch. So there was a point that we did our production migrations knowing that we would have to do a lot of manual cleanup and tagging and actually Michelle's team jumped in at that point to assist with the tagging and some other partners as well. But then there was a period where we were almost ready to launch the site and we had some optimistic target dates but then we ran into these performance problems and so there was about two months where the editors were updating the content on the new Drupal site and on SharePoint and then even a month after launch because we were still chasing down some errors that were concerning. We continued, so it was like three months of dual publishing which no one was happy about. Here, blue. A blue mask? Yeah, I'm doing that right now with another huge government organization and we took three pilots and two of them were narrow and deep and then one of them was media like news press releases and that gave us a broad. So I do like making an initial taxonomy that is broad and has that framework and then you drill down kind of proof and concept in one or two areas and you have questions like how granular do we need to be? Are we gonna be able to have a really semantic structure and not an organizational structure and you test those questions and those narrow ones but you then move on to the next one. It's like an onion or a pearl, I guess that's prettier and then you pull down those bigger ones but it really depends if it's not 60,000 things and that government level of complexity sometimes like going all in on the taxonomy and then you move things over piece by piece and you highlight it. You're like, hey, look how cool it is and people go, what are they doing over there? How come they got that? And you're like, but you can have it too. You just have to work with us on it. Absolutely, you have to get that framework because otherwise you'll be arguing over each word and you don't wanna argue over each word, you wanna go, no, we know how to deal with hyphens because you guys agreed to it in the framework. If you wanna go talk about the framework again we can change how we deal with hyphens but you don't get a hyphen and you can't have that apostrophe, we've already settled this and that's a really big thing is don't have term level arguments, have strategic high level arguments and have that governance so that you can say the director signed off on this and this is how we're doing it. Do we have time for a few more? Just follow up here. Yeah. You start. Yeah. So a couple of things there was, yeah, question. Couple of things, there was documents in some parts of SharePoint and other content management systems that had their own vocabulary as we saw that table there. So we did mapping on those and we were able to translate their Palestine to our Palestine and then I have some just homeworld Python scripts that looked for words in the title or the path and did a best guess and then the real technical secret to a migration like this is lots and lots of grad students that are, we have employed most of the McGill, Montreal's Graduate School of Library Science, everybody's summer job is tagging for us so we did like seven million pictures of cake for general mills and all of FedEx's digital assets are almost impossible to go from unstructured no metadata to metadata. So I would say map when you can, guess programmatically and then a whole bunch of grad students and have a nice Drupal view interface as your dashboard and then have stakeholders doing some QA and go from there and prioritize your content, start with the most recent high priority content and then you can launch while you're still working your way back through the stuff that's been programmatically tagged. Did that answer your question? Okay. Well, thanks everyone for coming. Yeah, feel free to find us out there. Thank you.