 as you might see by the slides coming up. So sometimes customers are difficult. They can ask really interesting questions which have difficult solutions. For example, can you not just make the search more like what Google does? We've got to go live in three days. We don't have any budget, and it must behave like Amazon does. That's my usual response. No. But actually, you don't have to worry too much. We're here to try to give you some tips on how you can make it be a little better without having to invest a lot of money. Yeah, so my name is Steven. I'm the head of Drupal at Calibrate. I've been doing Drupal since 2009. I've been here in 2013 as well. I like to describe myself as enthusiast, and passionate in anything I do. You can find me on LinkedIn or around the center, Congress. And my name is Joris. I do Drupal at Calibrate, and I also do some Laravel at Kodana, which is a sister company. And you can find me on Twitter. I'm also a maintainer of the Search API module and the Facets module. Co-maintenor, I should say, it's not a one-person job. It's a many, many person job. And we're here to say, don't panic. Yeah, the idea about the session is we don't want to take the technological approach for enhancing the search experience this time, because there's not any budget left. And we have to go live in three days. Instead of panicking, we're trying to take the creative approach and work with what's already inside the system and what we already have got. And that turns up looking something like in this video. So the way search works in Drupal is it's based on keyword frequency. That means that we're looking up how many times a certain keyword occurs in a text, which is kind of an all-the-way of doing it. It's great for if you're a library and you want to have academic researching stuff. But for users, it's kind of they have a certain intent when they're searching for something. If you go to Google and you search for buy an iPhone, you're not at all interested in all the pages on the internet that contain these two keywords. You're looking to buy an iPhone. So what we try to do for providing a good experience is trying to take into account what the intent of a user is while they're searching. And if you look at how Google does it, here I search for SpaceX. And Google knows that that's a company. So they assume that I might be looking for some company information, so they put a knowledge graph to the right. So that I can immediately see what I'm looking for if I was looking for company information. But they also provide me clear insights on what I can do on the home page of SpaceX. If there were any top tasks that I would want to do there, then I can see them immediately. Also, I might be looking for more information of other people's opinions about SpaceX. And I can find them using the top stories. Frequently asked questions are a great one, because that really helps people find what they're looking for faster. They also have videos about SpaceX. And only then are the regular search results shown. So that's almost completely at the bottom of the search. And the last one that's there is the search suggestions. And I think that's really interesting, because I always put the search suggestions at the top. Because I'm not as confident that my search will be as good, and Google is pretty confident about it. While we're talking about search experience, how do you set that up first and for all? You need to have good search results. And only then can we start looking at the experience part itself. So good search results start with good content to search through. So you have to invest in the content of your application, of your website, before you can actually do a lot of other things. So that's a good first step to talk with your customer, because it's not going to cost them money from the development agency to write better content. It's a good experience for them, because it's free. It's not free because it takes time, of course. But still, it's an easy way for them to improve their search results. And while if you have built a search, it's built up of a couple of different components, one of them being the server of the search. By default, that's a database. There's one thing that I want to point out here, which is the partial matching. So you can match on a whole word or match on parts of a word or words starting with a search keyword. There's a big performance hit when doing the default match on parts of words, but it gives you the most search results. But you have to think about the performance implication that this has. The database backend is a default that's being provided by Search API. It's easier for your operations team, because they know how to scale my SQL. They know how to run it. They don't have a lot of experience with it. They don't have anything new to introduce. It has probably sufficient functionality. As an anecdotal evidence for that, I asked Neil Drum earlier today. And the Drupal.org issue queues run on Search API DB with 1.2 million nodes in them. I'm guessing most of your customers don't have that kind of content or that many items. So it does introduce more stress on both the PHP and the MySQL backends or MySQL container server, whatever, because a lot more processing needs to happen in your PHP logic. On the other hand, Solar is more software to maintain, but it's easier to scale, because it's already something separate. It provides some AI and machine learning stuff, which we're not going to talk about, but know that it's there, and that you can do graph traversal and really interesting stuff like that. And it has Geospatial-based search, which is currently not possible in Search API DB. However, there's a patch, which is being used on croydon.gov.uk, I think that was the URL. So there's people out there using Geospatial stuff with Search API DB. But if you want to have advanced functionality about spatial information, then you need to go to Solar or Elastic or something else, something more clever. So the server defines where is all your data stored. The index defines what data goes into that server. So by default, we provide a lot of functionality already. One thing that I want to point out from this screen is the index items immediately. This allows you to, when an editor saves a piece of content, it will directly get written to the back end. Assuming, if you're using Solar, that the index time or the commit time is set to something very small. However, this does mean that your content editors will have some wait time when saving the note. If you disable this, your editors will gain a little bit of performance. But it might take two minutes or three minutes, depending on what time it gets indexed for the content to change to show up in your search. This is something that I cannot tell you which is the best approach. You have to decide together with the customer. Another thing is that we use rendered HTML output most often to configure how the index data goes into the back end. You could select all the different fields, but that's a lot of configuration. And it's a lot easier to just use the rendered HTML. If you do this, and I'm sorry that this is in Dutch, it's a screenshot that I took on the wrong language before noticing it. If you use the full content, I think is the English term for it. If you use that view mode and you have labels, for example, you have an address field somewhere on your page, and the label is address, every single item of that content type will have address in the search. If you make a custom view mode, then you can remove all the labels. And that way, your search results will be a little bit more specific. There's a lot of processors. It has a good default configuration for a database back end. There's a couple of processors that have some notes if you're using it on a different back end that it's not the right way. For example, highlighting is a lot more efficient when used in solar than in the processor. And then there's also boost settings. Here, I have shown that the places bundle type is boosted a lot higher than, for example, news. This is something that you have to talk with your customer with, but it's a good way to already refine what items show up near the top. There's more modules as well. There's not a complete module, which allows you to get not a complete. There's sorting. There's facets. And all of those things allow you to give your user a great experience. And because for me, a couple of years ago, that's where I stopped. I just threw all the search results on a page. And then it ended there with the search excerpt. And that was it. But then I started thinking we can do more about it. So the first thing we did is get the search suggestions all the way up front, even before someone is searching. Because that way, we can get them where they want to be faster. And the simplest way we can do that is just by using a specific search menu that the customer can maintain themselves. You can also use live results when you're using a suggestion. So it doesn't have to be a keyword suggestion. For this site, it really helped them get them to the products faster. And one thing that Google does that I think is really interesting is to group data based on the intent you think the user has. And you can do this by setting content types together or media types. So in this example, the FAQ items are at the top. And the media items are below. And then the actual search comes. And one of the most important things is the search snippet itself. Don't just use the excerpt, but add more relevant content about it. If you have a location, then it might be useful to have the address there. Or if it's just a specific landing page, the breadcrumb of that page tells you a lot on where that page is within the site and helps users figure out if that's part of the site I want to read. There are a lot of things you can define a search snippet on. But I'm going to skip that to go a bit further. This one is the kind of knowledge graph you're trying to do is if there's a location within the search results, we want to show that with the openings hours not to the side of it. And we ended up doing that by adding a search attachment to views. So a search attachment gets all the same view queries and exposed filters as the original view has. So it knows what's being searched. And then we've configured them to only show the location, and in this case also events, and just show one. So with the exact the same search, it just shows the first location or event within it. And then we've set up view modes just so that they're configured a bit different and that an event can look different than a location. The only code that's here is just to expose the search attachment as a block because you can't do that without the specific snippet here. And these FAQ items, they could be just a content type at the top. But if you look closely, I've searched for space, but there isn't actually space within the FAQ answer. So we try to take it a bit further. And the way we did that is by using facets. So the FAQ items there are pretty much the same as if it was a facet like that. So every content can have relations and entity references to FAQ items. They're not shown anywhere on the site just purely for the search results. And then we start at a facet on top. And we say we just want to show five sort by the ones that are found the most. And we use a view mode on the facet to make it look like an accordion item. And we show the raw results because we don't want a link afterwards behind it. So this means you have a couple of search results. And the most relevant FAQ items that are there are shown at the top to help people find where they're trying to go to. The facet view mode is a module I used to be able to select the view mode for each facet item. And there's a code snippet that I used to make the facet act without a link. And I already made a contributed module for the Dev Day. So I should have updated the slide. And I don't want to just stop there because the experience can go further than just the people that are searching and visiting on your site. You can also add search API indexes to add images. We use the search API index as on the media entities. So that allows people to search on every contextual item on the image. So Drupal Core mainly searches on the name of an image. But we have a lot of metadata on top of the media item. And because they're all in search, we can use entity browser and allow people to search for everything that's inside the pictures or any other entity when they're adding content anywhere on the site. So these are only a couple of suggestions of things that you can try to improve your search or the search experience of the user without actually having to do a lot of extra development. It's mainly configuration and some clever thinking that can already create a better solution. So the next time your customer is like, I want to have a search more like Google, we go live in three days. We don't have any money. It must behave like Amazon. You can say, no worries. We've got it. No problem. Or at least you can say, we can think about a solution. Yeah, thank you very much. So we used for our projects to save budget and time Agolia as an external search engine. It's really fast. But your results look really, really, really good. So did you make any experience with Agolia? So it's not that good integrated into Drupal? No, the search API Agolia module does exist. It allows for indexing, but I don't think it allows for viewing modes. But we have used it before mainly in our custom projects. And I think it works really well if you want something really fast without very small time to market. I'm sorry. So you can do this with Agolia as well. Just need some react work. OK, thank you.