 Hey, everybody, how's DrupalCon today? Good? Oh, come on. How's DrupalCon today? Woo! All right, we're just going to wait a couple of minutes for people to filter in some of these stragglers who aren't on time. I mean, we're all not on time. So we'll give it a couple of minutes. But just before we do, I just want to get a sense. How many people here are developers? Wow. All right. I don't think I need to ask any other questions. All righty, we're going to go ahead and get started. We do have a lot to cover today. For those of you who may be in the wrong room, welcome to Breaking Drupal Out of the Box with Augmented Reality and Beacons. I'm up here with my colleague, Chris Hamper. And my name is Preston So. This is a very exciting session today. I promise there's not going to be any live coding, but there may be a live demo. So with that, let me just go ahead and introduce ourselves. Chris is standing to my right, your left. Chris is a lifelong computer nerd. He's an Acquia certified developer. He's a colleague of mine at Acquia. We work together in the same department, Acquia Labs, which works on emerging technologies like conversational interfaces, machine learning, ARVR, and, of course, their integrations and intersections with Drupal. My name is Preston So. And once again, I want to say, how's this going? Welcome to all of you. I am the director of research and innovation at Acquia, where I work directly with our Office of the CTO, as well as Acquia Labs to really kind of further a lot of the open source and research initiatives that we have at Acquia and in the wider Drupal ecosystem. So just to get a little bit of color of what we're going to cover today, I want to talk a little bit about how Drupal and decoupled Drupal in general have evolved into this new mentality of moving away from a page-driven mentality. And augmented reality in Beacons in particular suggests a larger transition and a larger trajectory and a larger sea change in terms of a moving from a page-driven mentality to actually a geospatial or a locational, situational, even physical mentality. I want to talk a little bit about why you should be interested in augmented reality and why Beacons should be part of that kind of thinking. I want to dive a little bit into what it means to manage content for augmented reality and how our impressions and how our ideas about content management change and really morph in this context of augmented reality. Then I'm going to hand over the mic to my friend Chris who's going to dive right into the technical details. He's going to talk about how you can use augmented reality to drive Drupal content. We're going to have a demo showing augmented reality in Drupal using the example of a grocery store. Then we're going to dive right into the Beacons integrations with Drupal, the idea of how to integrate Beacons into Drupal. And finally, Chris will be demonstrating as well the idea of how we can combine Beacons and Drupal together in the context of an airport. And then finally, I want to do a little bit of meditation and maybe a little bit of discussion with all of you about this idea of what happens when you decontextualize content in the way that augmented reality and Beacons really do, because we're not talking about web pages anymore, my friends. With that, let's go ahead and get started. I want to start talking about what it means to move into this geospatial world. What is this transition that we're talking about? Why is it so important to so much of the analysts who are talking about it? Why is it so important to the brands who are doing it nowadays? And dive into just a little bit about why it is so important to us as Drupal developers as well. As many of you know with decoupled Drupal, content is increasingly needed everywhere. Every brand, every customer that you and I work with, they want to have their content everywhere, whether that's on a mobile device, whether that's on a conversational interface, whether that's on a single-page application powered by JavaScript. All of these things point towards a future where we are moving away from the sort of existing and traditional context of content in the past. One example of this is augmented reality. Let's just talk about what augmented reality means from a channel perspective, from a brand perspective. Augmented reality offers you flexible design over certain portions of what you're dealing with. For instance, with this idea of situational content, you can actually superimpose content over an existing view, such as your camera on your smartphone, and actually situationally reconfigure and change the way that content appears and what content appears next. Oftentimes, this right now is undertaken on a mobile device, and we'll be showing you demos that involve mobile devices today. And oftentimes, these interactions are powered by gestures and by motion. And there's something I'd like to call content proprioception, which is that if you imagine that all around us is a constellation of content, as you move around from place to place, the way that the content is around you and the way that the content actually interacts with you is going to be totally different. And that balance and that ability to really analyze and actually introspect how that content forms and how that content should work is something that is very new to those of us who are primarily used to things like web development. Now, what about something like beacon technology? Seems like a whole different space, it's really quite similar. But the difference is that beacon technology provides that fine-grained geospatial context and localization. Beacons, especially in the case of Bluetooth beacons, allow for this kind of bidirectional interaction and you can provide notifications that allow for the user to interact with additional content. So it's almost like a rabbit hole when you think about what beacons actually do in terms of their first step. But the world is not going to stop there. We're always going to keep evolving. There's always going to be more happening. What's next? We can never possibly know what channels are coming next and we have to be prepared for the fact that even more examples of situational geospatial content are going to appear in the near future. So this is some slides that I've actually presented before but we're moving away from this idea of standalone digital experiences to entire digital ecosystems and Drupal actually lies at the center of all of this. Drupal can serve as that content store for that single application but also a multitude of applications that all revolve and orbit around this thing known as Drupal. And relevant to today's talk, we're actually moving away from this idea of pole-based delivery where we actually request content towards this idea of push-based delivery. Well, where content comes to us without even us asking for it. This is a pretty big reinvention of content delivery that we're witnessing right now. And similarly, we're moving away from this idea of consuming content in a very limited way in a purely visual way and actually interacting content in a very rich way. And actually generating responses that change the way that content reacts to us afterwards. So our page-driven mentality is no longer relevant. When people ask me if the web-based CMS, the traditional CMS that operates on pages and operates on traditional web technology, is that dead? I would say yes, because we've moved into the omnichannel landscape. We've moved into an existence where we have to be thinking about much more than just our websites and our mobile applications. But what that means is that most of the web remains page-based. If you look at a lot of our other CMSs in our industry, the web is still page-based. Whereas our ideas of content are also still page-based. Our ideas around in-place editing, our ideas around managing the presentation of our content, the visual side of our content, that's still really page-based. That's still really focused on this idea that we have a web page, a fundamental screen in the case of a mobile app, something that is a single view, like a UI view in an iOS application, for instance. But we need to move away from that towards a geospatial mentality. We have to stop thinking about pages and start to think about decontextualized fields of content and decontextualized pieces of content. In this example, as you can see, we've got some beacons positioned around a men's clothing store. And we have to consider that, depending on where people are in the store, we might want to serve them different content. Proximity marketing is a new buzzword that's really taken hold in our industry today and in marketing around the digital industry as well. In IoT in particular, it's becoming a very big concern. And what that means is that as you become closer, as you go closer to something and as you actually approach something, you want to be able to interact with it in a very rich way. And brands have understood this. The most forward-looking brands right now are saying, how can I be able to reach my customers who are standing near my products in a store? Emerging trends today point to this idea of transparently immersive experiences, which means that if you are trying to reach your customer as a brand, you don't want to be this intrusive experience for them. You want to be able to provide them something that's not overly invasive, but is still immersive. So content today needs to be geospatial, physical, and situational. And what does that exactly mean? It means that content is completely decontextualized. It means that what we're used to, what we're used to in terms of content being on a page and content being a series of fields that can be edited on a note edit form, or content being able to be something that we can see and directly interact with is not the case anymore. Content is now in the context of a conversational interface, which means that it's totally out of its normal existence. Content is now part of Beacons and augmented reality, which means it's totally divorced from where we originally administered it. So what's the case for augmented reality with Beacons? Well, first of all, Beacons are here to stay. According to a report a couple of years ago by ABI Research by 2020, they estimate that shipments of Bluetooth-enabled Beacons will break 400 million in a matter of three years. Some big box stores in the US, for example, and the US is the most important market right now for Beacons and augmented reality, Target, Walmart, and Macy's, all three of these big brands have introduced Beacons technology onto their Salesforce. And Marriott has placed Beacons at 14 locations in their hotels to actually send promotional messages about some of the facilities that are available and the amenities available in their facilities. Increasingly, we're finding Beacons in more and more locations, in airports, in these big box stores that I mentioned, in hotels that allow for that seamless mobile check-in in museums and in restaurants. For example, what is happening in the augmented reality world? Well, nowadays in augmented reality, we're seeing a lot of growth in museology. Museologically speaking, augmented reality is a really big revolution because, for example, as you can see with the Smithsonian exhibit, the Skid and Bones exhibit allows you to actually hold up your device and see differences in content, differences in the media that you're experiencing as part of that museum visit. Augmented reality is also here to stay. In 2016, Forrester, one of the big analysts, said, companies will continue to experiment with AR and VR and that'll actually set the stage for a lot of the formal implementations that we'll see in 2018 and 2019. And recently, there was actually a Senate hearing on augmented reality and what it means for the future of commerce. So there's already these cases of content like museum exhibit information actually being displayed as augmented reality. But this idea of locational or situational content that combines beacons and augmented reality is increasingly important because there's this new intersection between what beacons can do and what augmented reality can do. And rather than actually simply showing additional information, like if I walk to a display and I actually hold up my phone to it, that means I have to actively go towards that place and have an explicit interaction with that actual exhibit. But with beacons, you could have a more passive implicit interaction where you actually get much more rich interaction with the user and also gathering of data, not to be creepy or anything. But what does this all mean? It means that content management has to evolve in a wholesale fashion. It means that we are seeing new solutions, new augmented reality focused CMSs, for example, LayR emerging. Although LayR has a very limited set of use cases, it's a very compelling example of why augmented reality has become so important to brands and digital marketers. And we would be wise as the Drupal community to pay attention to these trends. As I mentioned before, we can no longer think of content as pages. We can think of content now in the augmented reality context as experiential overlays or situational overlays. And as we see with augmented reality, content undergoes decontextualization. Take this example, for instance, a simple website which lists a couple of reviews and a couple of products. In the context of a grocery store with beacons, it totally morphs into a completely different experience. And this is something that a lot of brands are now paying very close attention to. So I want to end here before we switch over to Chris and the explanation of how technology can underpin this by asking a couple of questions. How should you manage content in this decontextualized way? Is there a way to consider content management in the physical world? And how can you organize that in the same way without having, for example, a world map that you have to place pins on? And how does this idea of situational content management really change our definition and our traditional ideas of web-based content management? So with that, I'm gonna hand over the keys to Chris who's gonna talk a little bit about exactly how we can integrate augmented reality with Drupal. Take it away, Chris. Thank you, Preston, and hello, everyone. I'm going to begin talking about a certain use case for integrating data held in a Drupal website with an augmented reality application running. I'm going to focus on a use case involving a smartphone or a tablet. That comes with some assumptions that you're going to be kind of looking at the scene through the built-in camera and it will be displaying that scene simultaneously on the screen. And you'll be kind of interacting with the related data through an overlay on the display. If you're creating that sort of application that comes with some requirements and dependencies that you need to include or take into account, first off is the fact that you have to develop a custom mobile application and that can be a pretty significant undertaking. But fortunately, to help you out, there are a number of augmented reality libraries that are available for Android and or iPhone. The library that I've used personally is called Euphoria, but there are quite a few other ones. One named AR Toolkit is available that's open source and there are quite a few others that you can find online. In addition to this, since you're going to be talking to a Drupal website through an API, you'll need some libraries to help you out with that sort of integration. I have tended to use JSON API when talking with Drupal because it's a very convenient API framework to work with and an Android application can use libraries called Moshi, JSON API and Retrofit to support that sort of communication. And finally, the last thing you need is the Drupal application that has your content on it and it needs to have the API fleshed out. Again, in my instance, it was using the JSON API module. So how does this work? The Euphoria library comes with a lot. It takes in the video from the built-in camera. It looks for images that it recognizes. These are called targets and it reports on those targets when they're recognized. In order to define a target, you need to capture its appearance ahead of time and incorporate it into some sort of database. This can be on the device itself or it can be a cloud-based recognition system. Each of these targets that you define by its appearance are given a unique ID, which is nice because you can use that to search your Drupal website to get the data that's related to that target. And once you get that content back, you can display that on the overlay user interface that you're going to create inside your application. So a more detailed description of what a target is. First off, you might have, for instance, a grocery store product like half a dozen eggs. Unfortunately, it's kind of a weird shape. It's not always easy for a computer to figure out what something is if it's not a nice box. So you might focus in on the label on the top, which is roughly rectangular, easy to photograph. So you take that out and upload that into your library. And once you've built your library, you can download it and build it into your app itself or you can rely on a cloud-based recognition system. Here's an architecture diagram. You have the software components, hopefully there's enough contrast, yes. The software components are in yellow, the hardware components are in gray inside the smartphone. You have the Vuforia library, which may be interacting with that cloud-based recognition system. And you can see it's pulling in video from the camera and very quickly recognizing targets and optionally drawing a 3D model over top of them or you can simplify that to a 2D object as well. And while it's recognizing these targets, it's passing that onto your application. You can perform whatever logic you need to determine what your application needs to do from there. And it will probably need to query the Drupal website for its data so it passes things through the JSON API libraries. Once it has that data, it passes on to Overlay UI, which is a native user interface for whatever type of smartphone you're developing on and that gets rendered again by the GPU on top of the scene information. And on the Drupal application side of things, you need the JSON API module to provide that API. So what are the challenges and risks with this approach? One challenge is getting good target images. There are certain things you need to keep in mind. The objects kind of need to be rectangular. Certain libraries extend that to things like cylinders and more complex objects, but that comes with their own unique issues. So while there is some flexibility around that, rectangles are easiest to work with. Other things you have to worry about are transparency or reflections in the object because those will change how the object looks to the camera and glossiness can also cause a problem because you can get lights reflecting off of the labels in weird ways. You're going to want this scene to be at least reasonably welded, otherwise the camera isn't going to be able to reliably detect things. And on the development side of things, the risk is that you're going to be writing and maintaining one or more mobile applications that can really be a big investment of time. Depending on what sort of things you want to do in that app, you may also need to understand some 3D graphics math. I personally have had to dive into that a bit. And a lot of libraries have pay to use model, either for a licensing fee or by a usage model. So that will be an additional consideration. But what are the rewards? First off, it's really cool. It tends to grab a lot of people's attention and it can get a lot of users noticing your product or service who might otherwise pass it by. And because it's AR, it's essentially immersing your user in the data. So as they're interacting with what you want them to interact with, they're getting the data that you'd like them to see at the same time. I'm going to try and give you a live demo, a bit of context for what I'm going to be doing. We have some grocery store products over here. I'm going to use a smartphone app to recognize them. They'll talk with the Drupal application over a JSON API and it'll respond with information on that, including the price and reviews. And all this data is done as you might use on an actual website. It uses a decimal fields for the price. It uses a review-based module to handle the reviews as comments and it pulls that structured data down and figures out what it needs to do with it. Fingers crossed that this will work. Yes, fingers crossed. And I have a video as a fallback in case it doesn't. So no worries. We prepared for this, we prepared for this, we learned. Okay, it looks like it's working. So as you can see, it's recording the scene around me. If I focus in on an object that I've made a target for, you'll get a little user interface that pops up. You can see it has the price listed on there and reviews are displayed. In this case, I'm just using the native Android user interface widgets. So it was very easy to create that user interface and yet it creates a very familiar user experience. You can see multiple reviews, it averages the stars together and everything. And for the content authoring experience, say the way cookies are on sale, just like any other Drupal website, this is a content type. And if this is integrated with your inventory system and your cash registers, you very well might just need to hop into your Drupal site to put something on sale and just click save. So the wifi holds up. I probably should have full screened this a bit. And ta-da, it's on sale for $1.49. Seems a pretty good deal to me. So that's AR. So how about beacons? Similarly, you can use beacons alongside Drupal by again using an API to get your data so that that aspect of the system is very similar to this example using augmented reality. To focus on the beacon side of things though, there is quite a bit of complexity. There are two fairly straightforward approaches you can take to use beacons. One is a standard called the physical web, which was developed by Google and a number of other organizations. There's also a feature on Android phones that comes with the phone called Google Nearby. Everything since I believe version 4.4 has it built in. And the other approach is a custom mobile app again. So for a physical web, it's a very simple interaction. When you get close to a beacon, it displays a notification on your phone that has the URL that the beacon is associated with and the page title that is pulled in from the website. And the user has the option to tap on that notification to open it in the web browser. So it's a very simple application but quite often all you need. What's required to implement this is a Bluetooth beacon that supports Eddystone, iBeacon or the alt beacon protocols, which pretty much includes all beacons or just about all beacons. You also need, of course, a webpage that has a public URL on it. And your smartphone or device needs a physical web client installed. As I mentioned, Android probably comes with this already. And for iPhone, you have the option of installing the Google Chrome app, which will give you a similar functionality. Of course, if a user does this, they also have to enable notifications, which unfortunately makes it a little more difficult to use to encourage a user to set up on an iPhone. And there are also some third party apps available that service the physical web protocol, though I don't personally have experience with them yet. So one option for using physical web is to use the Eddystone URL packet, which is kind of unique because it stores the URL directly on the beacon. The phone gets the link directly from the beacon, which simplifies things in some ways. The one major limitation about this is that the URL has to be pretty short, although you can use a URL shortening service to take care of this. And in that case, you can take advantage of some services that allow you to change the link after you have set it. So if your Bluetooth beacons are out in the field, you can still change the URL without having to go out and get them and reprogram them. The other way of using the physical web is using the rest of the Eddystone packet systems or iBeacon or alt beacon. In this case, you need to tell Google's beacon platform about your beacon. Each beacon has a unique ID on it, which you can register with Google's beacon platform. And after that, you can associate a URL with that unique ID. This URL can be any practical length. And this also comes with the advantage that you can change the URL through the cloud after the beacon has been deployed. So here's the physical web architecture. You have the Bluetooth beacon communicating with the phone or recognized by the phone through the Bluetooth radio. It passes that beacon information to the Google nearby service. And if it's not an Eddystone URL type of beacon, then it doesn't look up out to the cloud and passes that URL optionally to a web browser. In the case of using Drupal application, then that web browser will communicate directly with your Drupal site. The challenges associated with this are pretty minor. All you have to do is either program the URL into the beacon. The method for doing this depends on the manufacturer and what kind of tool set they have developed. Or ultimately, you have to register the beacon with Google, which is also a relatively straightforward process once you've done it once, it's pretty simple. Some risks and limitations, as I mentioned with the Eddystone URL beacon specifically, there's the URL length limit. Some clients require an HTTPS URL before they'll openly display the notification, which is something to take into consideration. And the last downside is that the users need to have those features enabled onto their phone. It's generally a bit easier than getting them to install a separate app, but if they haven't done it yet on their phone, then they might not even see your notification. Also, the user has to be actively using their phone because the physical web notifications don't actually wake up and vibrate and beep your phone. You have to look at your notifications and notice that there is a nearby beacon. And overall, the control that you have over the user interaction is very limited. All you have is the notification and giving the user an option to open a web page. In some cases that's enough, but often you want more than that. The biggest benefits are absolutely no development required for a smartphone app. You can just use what's already on the phone and you don't have to convince your user to install an app. Oftentimes that can take a real concerted marketing effort in order to be successful. The other approach is to use a custom smartphone app. In this case, the app detects the nearby beacon. Again, it notices it's a unique ID and then it can do whatever it wants to with that ID. In this case, it needs to get some more content so it will again use JSON API. It can do a query based on that beacon's ID and get whatever data should be associated with that location. And of course, you can also use CoreRest or GraphQL or any, even a custom rolled API if that was what you prefer. Again, this works with practically any Bluetooth low energy beacon that you see on the market today. You also need the Drupal site again that has your custom content and it needs to have an API enabled on it. And you need to develop a smartphone app. Similarly to the augmented reality use case, you can use some supporting libraries to help you integrate with your API. Again, I personally have used Moshi, JSON API and Retrofit. And the application is again looking pretty similar to the previous ones at the bottom at least. You have the JSON API integration with the Drupal again. And you also have the Bluetooth recognition coming in through a Bluetooth radio. If the beacon manufacturer has provided an SDK which oftentimes simplifies things, it may be what interacts directly with the Bluetooth radio. Otherwise, you'll need to use the Android's built-in services. Again, your app can use whatever logic it needs to determine how to act. And it can display the related content that has gotten from the Drupal website through the user interface. The biggest challenges for this approach are writing and maintaining the apps. If you're trying to support all devices, you might have to create different apps for different operating systems, which can again be a big development load. Though there are some hybrid app frameworks that you can use if they have a built-in Bluetooth Low Energy API that can really simplify things. The other big hurdle is convincing users to install your app. Again, this can take a concerted effort to accomplish. And also, since you're serving an API, you need to of course maintain the infrastructure that services that alongside the Drupal website. Oftentimes, that's a little bit of a different use case than just a straight-up Drupal site. So that might require a bit of extra expertise depending on the system's specifications. But the biggest benefit, and it's a big one, is that you have full control over the user experience. Anything that you can make an app do, you can do. So the sky's the limit with this approach. And another demo. This time, since it's kind of hard to demo, it begins in such a constrained environment when they're in close proximity to each other. We just settled for doing a video right off the bat. We got one of our teammates, Ted, to be our actor for this description of the scenario. It's a theoretical Drupal International Airport, which Preston has come up with a slogan for, as you can see. Fly the friendly form AP Sky. Okay, all right. Apologies for that. I'm sorry. So as with any airport, you have secured areas and unsecured areas. So you kind of have a traffic funnel system that can help you to place beacons strategically. You might have a beacon at the airport entries to trigger one action. You might have beacons after security checkpoints to trigger other actions. And for people who are arriving through a plane, you might have beacons right at the exits from the planes to trigger yet another interaction. So as the user passes through this course, they'll get first, in our scenario, they'll first get a physical web notification when they enter the airport. That'll suggest that they install an app, which we'll assume that they do. After that, they'll pass through security, which will trigger another action this time using the custom app rather than the physical web. And then finally, you'll see what happens when the passenger debarks from the plane and triggers yet another action on the native app. So here we have Ted arriving at the airport. It's actually our hotel. And you can see it passed by a bit more quickly, but this is the physical web notification and Ted clicks on it and it takes him to the Drupal site. Says, get the app on Google Play, okay. Now he's just passed through security, he's installed the app. He passes by another beacon, which triggers a native notification, which brings him directly to the screen that shows what gate and arrival time. He can make sure the flight is still on time. And this is all using data pulled from an actual Drupal website, using a native Android user interface. The time is even calculated dynamically. And finally, he's come back from his trip to Austria and he passes another beacon. He needs to know where to pick up his luggage, which is convenient because the app tells him his baggage will be waiting at carousel three. And again, that's just more data pulled from the Drupal website and that wraps it up. Pretty cool. So, you know, first of all, let's just give another round of applause for those amazing demos. I mean, that was pretty cool, right? The thing that really carries across all of these technologies and these demos is that Drupal is the common thread. We use Drupal to actually serve out the content when it came to those grocery store products. We use Drupal to serve out the content when it came to actually getting that airport information out. And this really presents a host of really great opportunities for Drupal in ways that we have never been able to imagine before. I mean, you can just think of all the possibilities. These are only just a couple of use cases that have captured the attention of not only the Drupal community today and many of us here in this room, but also people in our customer bases and people that we work with on a daily basis. So, just to finish off here, I want to talk briefly before we get into questions about what this actually means for content and what this actually means for Drupal and how we can think about the context of content in a decontextualized world. As we've seen from this example, you can't just go to a Drupal site on a native mobile app and expect to get a full list of your flights from that airport. You want to be able to get a single sample. You want to get a single flight that's personalized to you. You want to get a single product that you're standing in front of. Because you as the user no longer have time to go and seek out every single piece of every single item that you might want to grab or every single flight that is available at the airport. It's just not feasible. And so the question really becomes when content really loses its context, when we lose the thread of having all of these flights in a list or having all these grocery store products right up there on the catalog, what does that mean when it comes to the fact that CMS has actually contextualized all of this stuff by design, right? Context is a very important concept in CMSs, especially in Drupal. And so I want to pose a couple of questions and maybe this is something that we can use as a starting point for discussion or as some interesting food for thought, which is how can Drupal administer content for augmented reality? You saw that earlier example of LayR CMS. The value proposition of LayR CMS is really to allow you to take a picture of something, right, a sort of rectangular image just like the ones that we have used for these grocery store examples to actually provide an additional overlay over that that appears on your phone. And that's really what it can do in the context of providing content. But when you think about the fact that Drupal has all this rich content modeling functionality, it has a very rich ability to be API first, you have to think about what contexts that content will be delivered to. And when you think about how it can work in the context of augmented reality, things become very interesting. And so just as we administer context in the traditional sense on a Drupal website, whether that's as part of a view or as part of an ending reference or as part of whatever it may be that we are putting that context into could be something like panels. How do we administer physical context? How do we get to the point where we can actually use things like geolocation and put content in totally new places beyond our screen? It's a really interesting idea, a really interesting thought to ponder. So is our new blank canvas that sort of blank white page that we always end up with when we're stuck building a new website or stuck making some new mock ups or stuck thinking about what could be next beyond the screen? Is our new blank canvas that world map, that limitless world map and not a blank web page? Now here's some food for thought. I'd love to leave you all with these questions as you think about what this might mean for you if you'd like to try out some of these technologies. If you wanna think about what augmented reality and beacons could mean for you and your clients and your builds and what you're doing with decoupled Drupal, what would a user experience like this look like? And how would you build something like this? And can we successfully orchestrate in Drupal across both beacons and augmented reality in a compelling way? And how should Drupal prepare for augmented reality and beacons? Or should it? And how will you prepare for that future as well? And there's a single question that somebody asked me when I told him that we were gonna give this presentation and they asked me, well, I think Drupal should really only be used for augmented reality and beacons if it's part of that larger digital experience ecosystem. And I wanna be a little bit retrospective here and harken back to what Dries said during his keynote and in the past as well. Drupal is for ambitious digital experiences. Isn't this an example of one of those ambitious digital experiences? And if we want to make Drupal the single source of truth for all content and make Drupal the sort of main arbiter of all of this content and make Drupal the one that rules them all, isn't it important for us to consider these use cases too? With that, I just want to end here and tell you that there is another decoupled Drupal that I will be delivering tomorrow at 10.45, right here back in this room about some of the future of decoupled Drupal, some of these ideas around content editing and site building in Drupal and what it means for our future. It's gonna be a little bit more heavy on open discussion. And of course, we have the sprints on Friday. Please do join us if you want to think about decoupled Drupal and some of the ways that you can improve the experience that your developers use to potentially build something like augmented reality-based interfaces. Please do come on Friday. And finally, please do evaluate the session. We'd love to hear what you thought. We'd love to get your feedback. If you love those demos, if you hated my hair, please do let us know in the evaluation form. And Fiden Dank, thank you very much and also thank you to our actors as well. And we'll take questions now. There's a microphone over here. If anyone would like to ask some questions or? So in your experience, when things can start getting nasty with the amount of content that a website can have, for example, I have, let's say, an art website with 20,000 of artworks all around the world. So potentially, I could be, it's a rectangular, it's a high quality images and they are ready. So it's a good candidate for an app that I can build and going anywhere in the world and scanning and getting information. But 20,000 of items will slow down the app. So there is a limit on the quantity of content. Yes. That limit tends to vary depending on what augmented reality libraries you use, but generally, probably not more than 100 targets stored on the device itself. If you want to go above that, you generally have to use some sort of cloud-based recognition service. And that does increase latency and requires network connection. It comes with some downsides, but it's kind of what you need to do if you're going to be utilizing a large target set. First of all, that was a great presentation and really cool. Thank you. I have two questions. First is regarding to the AR. I mean, have you experimented in anything regarding giving back the power to upload the images to the user? For example, in the grocery shop example that you gave, if the employees of the grocery store want to upload new products and stuff, is there a way to do that and maybe sync it with a Drupal interface and it calls something else or something like that? Oh, sorry. Let me try to re-summarize the question. So is there a way in the Drupal interface potentially to upload those images that need to be put into the database set? Is there currently, would theoretically be possible, using the API for whatever library or service you're using for cloud-based recognition? So it certainly could be done. I don't think there's a Drupal module that does that yet, though. The second question is regarding the beacons. And I wanted to ask, is there, I mean, maybe this is more of like a challenge. We could probably look at, from that first notification that the user get, we could maybe ask an information about what's your flight number, save that in the browser and use that to give them information as they go across without having to have them install the app. Do you think that's something that's walkable? Yes, that certainly could be approach that could be used in a lot of cases at the examples that the scenario that we gave was a little bit contrived, but we wanted to come up with something that felt cohesive and something that people could recognize and connect with. So, yeah, a lot of what I did for the demo could be done in other ways. It might not require the installation of an app, but it was meant as a demonstration of what could be done, yeah. Thanks. Thanks very much. Any other questions? Well, we'll stand over here to the side. We've got about 10 minutes left if you'd like to ask us some questions personally. And thank you once again. I hope that you enjoyed it and yes, thank you.