 We're just going to run through a couple of ideas that we've had for our decoupled environment, especially with the focus on the editors today. So it's a topic that I think doesn't get enough attention actually. My name is Jeremy Chinquist. I'm actually a project manager at Dronomics in Vienna. I've gotten education, master's degree, bachelor of arts, as well as I do a lot of work with the Drupal Austria community and a few other organizations as well. So we have a decoupled setup, lupus decoupled content pool and a normal Drupal, decoupled Drupal. One of the challenges that we face is that the editors themselves lose context when they're in the front end. They just have the front end and that's it. So decoupled environments tend to just leave them hanging. Things like the edit button, the delete button, for the preview methods, all of those things are just not there when you're looking at a website that's a decoupled website. Other information as well is missing. Publishing status, state time, moderation status, revisions, all of that stuff. So yeah. I'd like to first, before I go into our solution, I'd like to actually talk about the fact that we have several different projects that we're doing with decoupled solutions. Valuita, Teh, Virchevsferlag, Career, which is a larger media house in Austria. We've worked with all of these people and have exchanged information, so yeah, we have several projects. Developers love to have decoupled solutions, why all of these reasons, performance, security, all of these things help us a lot and make the project really cool. However, the editors, they tend to start to take two browsers in order to be able to preview their content on the front end after changing it. One of the biggest things that I've actually seen from journalists is that they will publish content so that they can preview it and then take it down. In the worst case scenario, actually, Google found it and already indexed it. So yeah, you don't wanna have that type of stuff. In the worst case scenarios, I've actually seen that the journalists get very frustrated and will even reject the CMS. I mean, we've all heard that people have complained about Drupal a lot and yeah, trying to mitigate those frustrations is a big part of our work. So how can we make that experience be optimized in a decoupled environment? We're going to enable the content creators to have that access that they need as well as giving them information about publishing status and other things like that in the decoupled front end. So one of the things that we cannot lose track of, however, is you have to give the search engines and the anonymous readers also the same experience of the decoupled front end without detracting from it. So I'm gonna skip over this slide. You can take a look at it. As I said on the drunomics.com website, we've actually, I've published the slides so you could download them. Just go to drunomics.com slash blog and it's the top blog entry at the moment. So here's one of our previews. This is actually a decoupled site that we have, live value.tay, as you can see, very basic, but we've got the tabs from the backend that are loaded. So actually the person is logged in at this point in the front end and pulling Drupal content, Drupal administrative, the Drupal administrative menu for that content. How are we doing that? We have a setup so that you go to a URL, similar to login, but in the front end you actually click on the button. That will load the resource. It's just a simple, quick loading so that you're loading the resources and then it's going to check the backend or you logged in as an editor or a content contributor. If not, it's going to direct you to the backend that we have and ask you to log in there. If you're already logged in there, that's fine, you're good to go. And then you can actually go on to your content and at this point you're going to be loading the resources. So we've optimized for Google, we've optimized for the anonymous user and now we're loading at least some information for the content editor that they need on the front end. It doesn't look wonderful, it's just the Drupal tabs at this point. So we're going to take it a step further in the next couple of months here. However, actually one of our solutions that we've done for Virchev's for log is to when you're logged in, we are not loading the advertisements. We're actually presenting some metadata about the advertisements as well. There's a couple other optimizations in there but we got feedback that for the content creator being able to see the ad ID number was a good thing so that they could kind of keep that in their mind, see what advertisements they're loading for that page and keep in mind that this is also one of six different websites that's pulling from a content pool back end so it's a decoupled setup and we have six different websites, all of them with different IDs and such. It's good to have this type of information for those content editors and the site administrators. We've had a discussion as well about simply loading the admin toolbar in the front end and I will come back to that in a few minutes. So our proposed solution for the next couple of months, we are going to move those tabs that are loaded into something that's more of a custom design. The reason for this is to, we want to highlight the things that the content creator needs actually right away. We want to give them the ability to do one click to get to the edit and to have it in a situation where it's even if you scroll down, it's still available. We're actually going to improve on the logout that we have at the moment so you can log out and keep a minimum of the toolbar active or you can log out completely and have it hidden and we'll see how that's gonna be adopted as well. So I mean, we're also really trying to get some feedback on this. I would love to have feedback later on. Yeah, we'll come back to that. So we're going to improve the placement. We're going to make it more compact and we're going to try to, we're going to improve the usability of those tabs, make them available. A couple of other things that we've made improvements on. So because this is a decoupled environment, in the back end, we've given a link to the API output that's available for content creators. They can literally see what the JSON output looks like that will be passed to the front end. They have that available. For some of the product owners that I have, I've actually gotten feedback that they can see that too and then they can tell us if there's something wrong there or they've expected something. So some of them are very active about using it. We've made a couple of other, this is our lupus distribution and we've made a couple of good enhancements to the top menu as well. We've given a handbook there which the handbook will give the, not only the content creators, but also the product owners on their side, valuable information as to how this website is supposed to be used. Because it's a decoupled environment, and actually I should have mentioned this earlier, it's not only a decoupled environment in this case, but it's a statically generated front end. So what's actually happening is you'll edit something in the Drupal system and a person who is logged in will get that updated stuff immediately, we'll see it in the front end immediately, but for anybody else who's not logged in and not loading those resources, the site is statically generated and every 10 minutes or so, the static generation will be triggered on cron run, updates the front end, it's static, it's loading fast, but the people who are logged in get the information that they need as well. So that's why we have these zero changes up in the top there. We're informing the content editor as well that there are some things, well if in this case there's everything in the front end is updated, right now you're seeing the updated front end. Yeah. Wow, this presentation has gone really fast. Unfortunately we have to leave you hanging there because the next step for us is to actually implement this toolbar to get feedback, to get feedback from the editors as well, but hopefully to get also feedback that'll make them feel more comfortable with using Drupal, using the decoupled setup that we've had because of course we wanna have the journalists happy. Yeah. So I had a really interesting talk yesterday with Fabien Frantz. A few of you might know him. If you don't please look him up, he's a very fascinating person. As we were discussing he said okay, well our solution is to bring the back end to the front end, we're loading it on the front end, and he said no, no, no, you don't wanna do that. Bring the, yeah. Basically reverse it, keep the editors in the back end, he said, and you're going to load the front end into the back end. It's an interesting approach. Actually my colleague and the CEO of our company, Wolfgang Siegler, you might know him as Fago, sitting up in front here. He actually had a longer discussion about it too, and so we're going to possibly reverse it, see about it, but as I said, I'd be also interested in getting other people's approaches to it, your ideas. So I'd like to open this up. Okay, a few references first. I'd like to actually open this up to a conversation. If there's enough interest to generate it, I could even see about organizing a bof tomorrow, or people can just simply come up and talk to me on it, but I'd be really happy to take your questions now. So you didn't mention explicitly in line editing, that sort of clicking things and changing them, I'm guessing there's some aspect of that going on here? Not actually in the front end, you're in the front end, no. When you mentioned taking the front end to the back end, what we did is on a project to make it feel not like the front end, but actually in the admin system, is we heavily use the form API to have custom fields that look like the front end and then populated other ones, and that sort of stuff going on. So it's, yeah. We haven't mixed that, but I mean, that's more of a technical, honestly, I'm not involved in the technical aspect of it at this moment. So I would really ask that you come and talk to Wolfgang about it, because he would be more able to answer the implementation. But yeah, the inline editing part is really just clicking, especially for headers and things, was really what makes a big difference to some of our clients. Okay. Maybe you could also post in there a link to the website that you actually developed for it or something. All right, next question. Or I'll read it from the app, one minute. Okay, one question is what about front end preview link from the Drupal backend, the next JS for Drupal? Provide this feature, mention this as inline preview built into the editing interface. As far as I understand the preview, it actually is working. I hope that Wolfgang is, yes, good. Thank you. Yeah, so there is the preview link in the backend and if you click on it, you can see it as it would be a normal preview. Okay. True. Wolfgang mentioned that we just do a redirect so that you do actually see it in the front end. The permissions are set up that way. Yeah, so you get the preview. All right, the next one is what's wrong with two windows as a developer? We usually have code and browser. Having yourself logged out in a second window to be looking at it is really the problem because I've seen it all too often that an editor will actually publish the content so they can look at it in the front end separately. And I guess that's the main point is that they've actually published the content which is a really big no-go for me. I don't wanna see it indexed on Google simply because they need to have a preview. All right, anyone else have a question? I think that's it. Well, I'm available for talking so if anyone wants to come up. Okay, thank you.