 Sounds great. Fabulous. Hello everyone. Alright, I'm going to stop looking at myself. Alright, good afternoon chickens. Thanks for tuning in to Previous Next Showcase at Drup1. I'm going to cover our recent work in Australia's higher education sector. So first off, who am I? I'm Griffin Heels, part of the Agile Delivery Management Team at Previous Next. I love going to the movies, eating Red Rock, Deli Sweet, Chili Chips, someone on the desk already, and changing my facial hair, as you can see from these different photos and what I look like right now. I'm also involved in the Drupal Community Initiative bug smash and coordinating the Code Sprint Day tomorrow. Right, so what are we going to cover today? Well, this afternoon I'm going to talk about what problems Australian universities are facing and what solutions, specifically Drupal solutions, we're implementing to support these teams. I'll also leave some time at the end to answer any questions from the session. Alternatively, feel free to reach out to me on socials via the Drupal AUNZ Slack channel. So a quick overview of Previous Next. Previous Next is Australia's most experienced Drupal agency. We provide full service consulting, design and development for Drupal website. We've got a very experienced team and a heavy involvement in the community, as you can see from the schedule today, and we prioritize contribution. Right, let's get into it. Who have we worked with? Lots of people in the higher education space. Specific shout outs to CDU in Darwin, UTS in Sydney and UQ in Brisbane, as they're all my clients. So what problems are Australian universities facing at the moment? Well, a few key pieces of feedback are consistent from our higher education clients. They're primarily small teams working with lean budgets. There's a lot of content and digital real estate to oversee. Some of these units have 20 plus sites across different versions of Drupal. There's a large focus on their digital presence at the moment, especially during and post COVID, with a target on attracting international students. So it's not just a primarily a domestic market. It's international. It's multilingual. It's a wide scope. And it's a very competitive landscape. This all boils down to small teams needing to do more with less. As a strategic partner, we need to provide solutions that address these problems directly. Our aim is to empower these in-house teams so that they can reach these new audiences and maintain their sites without consistent development involvement. So what solutions are we implementing to support these guys? Our most frequent recommendation to Australian universities has been to move to layout builder as a way of introducing editorial flexibility and control. Previous Next is a major contributor to Drupal's layout builder ecosystem. It's our preferred approach when constructing landing pages as it allows content authors to mix and match components from their design system to build complex pages. Content authors can edit and drag and drop components with a live preview of how the pages will display as they work. Working with your design team, a library of layouts and components is developed that gives content authors maximum flexibility whilst remaining within the guardrails of your design system. Using this approach, page templates aren't fixed, and that means there is a wide range of variations and combinations that can be achieved on the site without development involvement. It's really key. Many of our university clients' sites weren't built initially with layout builder. Instead, we've migrated one or several of their existing content types for the improved editorial experience. So that's a key thing to remember is that if you're not using layout builder right now, you can move to it even in a reduced section of your site. So you could move your articles content type and see if that works for you. It is worth calling out that there is a development investment to migrate to layout builder if the site wasn't built this way initially. However, we've found that our clients instantly prefer this approach compared to paragraphs or other content management approaches. Right, that's all the details. Let's look at some examples. So a great example of layout builder in action is the University of Queensland Future Students Content Hub. You can Google this UQ Future Students if you'd like to have a look alongside. As part of a site refresh in 2020, we're going to do the next work with UQ's in-house web team to deliver a suite of flexible components that their content and marketing teams could manipulate and reuse as required. A few key components to call out here that you can see on my lovely presentation. We've got a hero component there on the left which has a number of editable elements. So you've got your headline, subtitles, button text, and background imagery. You've got a tiles component which has a three up reference content within Future Students or other parts of the UQ site and easily add more rows and manipulate them as you need. You've got an icon grid component. So you've got an optional head and subtitle text there if that's necessary on the specific page you're talking about and a pre-built icon suite. So you might have a number of icons to select from that are in the desired style. So that marketers or content admins can jump in and update these as they want to. It is really important to call out that these pieces can be reordered and edited in real time with a preview so minimal Drupal CMS experience is required. Additionally, this content changes seamlessly for different student types. So if you swap to international student at the top of the page, you'll receive unique content for that user type. Another example of an effective layout builder implementation is on Charles Darwin University's new course page designs. These are in the final stages of content publishing and approval so there's no live link to review. However, they should be going live in the next few weeks. Using Layout Builder, complex landing pages can be built with content from a number of sources. Alongside your CMS entered data, CDUs new content pages feature components that are automatically populated via API from their external curriculum platform. So you can see some key elements of this. So at the top there, you've got your key facts, which features content that's pulled automatically from the course API so it's always up to date. Additionally, you could hide, say for example, the intake field at the top there if it's not relevant for the specific course or not up to date. Let's talk about some editorial sections. So you've got two flexible marketing components there. There's the sort of standard copy one where you can add images, videos or additional text and as well you've got a testimonial component there that allows for images and copy. More components will be added in future phases that editors can drop into pages as needed. For example, you might want a large scale video one or a click, click, click little gallery. This approach of automated content alongside the editorial content keeps consistency by relying on the course API as a single source of truth while also allowing for the flexibility and space required by the marketing department. Last little bit about Layout Builder. So when implementing Layout Builder, we've found that the out-of-the-box experience needs a bit of polish especially to support new editors that are new to Drupal. As part of the Move to Layout Builder, we often look to reduce and restrict default options as much as possible so that the CMS isn't confusing and new users can pick it up quickly as well as review the naming of sections, components and configuration options. So you could see on the left there we've got some clear layouts that a user could go, okay visually I know what that one's going to do. There's the tiles at the bottom or the naming is very clear. Also we're looking to add like subtitles. Say on the right you could see below the top text is below in a smaller font size so a new user can jump in very quickly and know, okay, I have a very clear understanding of what this is going to do. All of this together, so our previous examples and these editorial improvements lead to small university web and content teams that are able to update and maintain complex and interesting landing pages without developer involvement. Right, let's talk about another solution which is content hierarchy. Previous next is the author and maintainer of Drupal's entity hierarchy module which allows content to be easily modelled in a hierarchy. This module is in use on sites with over 20,000 pages and is used on Australian government websites to receive more than 80 million page views a month. So it's solid. It could take extremely large page trees of content and a huge amount of traffic. With content structured in a hierarchy it is substantially easier for the user university's web team and editors to use and organise and navigation becomes simpler for the end user. Entity hierarchy also powers URL generation and can be extended with a sub module to provide microsites within your existing Drupal CMS. So let's jump on that now. So Charles Darwin University uses entity hierarchy to power its in-page navigation, so on the left-hand side in that top screenshot there, and breadcrumbs, you know what breadcrumbs are, as well as the URL generation. However, it also takes this functionality a step further with the ability to create microsites within the existing CMS. It does this by designating one page as the microsite parent, which can be used to have a secondary navigation bar, unique logo and title elements. So if you look at this second screenshot here, you can see the microsite within CDUs existing CMS for the research institute called Reel. So just outside of that shot there is the CMS navigation bar, so that remains, so users already know they're on the CDU site, but it's got its own unique title, logo and nav bar so they can work in that sort of section of the site. This has been used by other university clients to consolidate separate sites into the main CMS. For example, research programs like Reel, university colleges and other small, you know, departments within the university. This is very powerful as the microsites inherit all of your existing site styling and existing CMS functionality without the overhead of maintaining a separate Drupal instance. So that goes and sort of addresses that second problem we talked about earlier around, you know, digital portfolio and oversight. The more you can bring into your CMS and inherit that functionality that you already know how to use the better. So while it's a little bit less flashy than Layout Builder, the Entity Hierarchy module does a lot of the heavy lifting in the back end and can make the maintenance and oversight of a suite of Drupal properties much more manageable for small teams. Oh, I clicked on the link. Don't do that. Hopefully I'm still sharing. Oh, there we go. I'll just click there. All right, good. FAB. So my last solution I'm going to talk about is resource recommendations. So previous next is the author and maintainer of Drupal's backfill formatted module. This was written to automatically suggest and recommend content to users based on its similarity with other content. This is used in a lot of ways by Australia universities, primarily to suggest related courses and events to what you're currently looking at. Having this content automatically generated saves substantial time for content editors and ensures there's always a next step for users in their journey. So content recommendations, University of Queensland. With the backfill formatted module, content recommendations are generated between related pieces of content in the CMS. So you can see from this screenshot, we're currently on the Agribusiness MBA page and in the story section, we're displaying, you know, Agribusiness related articles, as well as MBA related content in an order of relevance. Additionally, at the bottom there in that explore other programs screenshot, you can see similar courses that are also suggested to the user. It is worth pointing out the content admins have full control over these recommendations with the ability to potentially manipulate the first or second position in the stories and then the third one is automatically filled with content that the CMS deems relevant. So you can always make sure that what you want is in the first position but there's always stuff, more things to click on. This flexibility ensures that users always have something relevant to click on and that the web team don't have to update every single course page and make sure there's three things in every position over your, you know, 200 something courses every time something changed. Whew, okay. Let's have a bit of a breather. I feel like I've just trained it a lot. Anyway, that was a lot of information. So let's just take a quick moment to recap. We discussed the main problems at the universities that are facing in 2021 which are they've got small teams and lean budgets. There's a lot of digital real estate to oversee. There's a lot of eyes on these digital properties and there's a lot of competition in this space. So to address each of these issues we recommend you take a look at Layout Builder to empower your marketing teams and ensure there's flexibility in your landing pages. Content hierarchies using the entity heart reference hierarchy module to create content relationships and potentially build microsites. And finally, you looking at resource recommendations using the backfill formatter module to recommend accurate related content to users. All in all, using Drupal, supported by these modules will go a long way to addressing the main pay points of an Australian university in 2021. Any questions? You just answered everything, Matt. I'm seeing some people chat but I'll get distracted so I'll just... If there's no questions I might hand over to you, Nick. I think I can do that. I'm on air. Look at me. Cool, everybody. So my name's Nick Xu and I'm here to talk about Skipper. I'm Operations Lead at previous Next which means that I deal with a lot of complex hosting related architectures and the like and then that funnels into Skipper where I'm a lead architect and do everything from kind of architecting the platform to then building solutions on top of it. So probably one of the most recent things we shipped was that RDS proxy feature for NSW.gov.au. So we get to work on some pretty cool stuff with some pretty cool people. But back to Skipper. So what is Skipper? So it's a scalable cloud hosting platform specifically designed to maximize the productivity of development teams. It's a bit of a mouthful but at the end of the day it's all about productivity, maximizing productivity. And for this talk I really want to focus on maximizing productivity for decoupled web apps. So just a quick look in what is decoupled based on the last couple of Drupal Souths and also what I've heard from other talks around Drupal South. It sounds like people kind of know what decoupled is so I'll just take 30 seconds of your time to make sure everybody's up to speed. But breaking it down and simplifying it we have a view, we have content. And traditionally in Drupal that's all been in the one app so you'd be writing templates or themes in Drupal as well as editing your content. Whereas after you're kind of taking the view layer out and then writing that in a different framework and then consuming content through an API. If this was a movie this would essentially be face off. It would just be taking the display straight off. So I swear that's my only joke. But in this context I want to take search and then decouple it. So that's what we're going to do here as our context for how Skipper works. And this is the app that we're building. So to kind of break this down, I will break this down and simplify it out a bit and talk about each component but this is where we're starting. So first of all we need, we're going to keep Drupal. We'll keep Drupal around. For this demo we're using Umami. So because I didn't really want to write a bunch of content and Umami looks better than I could ever theme or ever create. So it's amazing including the recipes. But for this we're using Drupal and then we're going to tie it into Elasticsearch. So you can see the red dots around Elasticsearch. So Drupal is going to take all that Umami content and then index it into Elasticsearch. From there we're then, oh sorry, and for this we're using OpenSearch. So there'll be a little bit of AWS in here but for this we're using OpenSearch which is AWS' distribution of Elasticsearch and it's all hosted highly available. It's a really good service. I personally really like it. But at the end of the day we're then going to use a proxy app in front. Now let's just talk about this relationship a bit. So between Drupal, Elasticsearch and the proxy app while we're at this point. So Drupal is indexing all the content in Elasticsearch and then proxy app is designed to then expose that content. But what we have here is we want to have separate credentials. We want separate access for these kinds of things. We want Drupal to be able to write and then we want proxy app essentially to be able to read and then have permissions around that. And OpenSearch has a very robust RBAC system which allows us to do this and provide credentials to each one. So then one's the writer and one's the reader. If you'd like to know a little bit more about proxy app we have a blog post on skipper.com.au and it's not specifically designed for Elasticsearch. It's really like a reverse proxy that then attaches HTTP auth onto the backend request. So you get some identity between the public endpoint and the thing that's connecting to the backend. And we have one last piece, the face. The face we're taking off. So in this case I wrote a React app and it looks a little something like this. We'll go into this in a little bit more detail. But if we go back to the architecture diagram we're kind of combining two pieces here. So we're deploying our React application and I've specifically called out Cloud Front here because Cloud Front is not only routing traffic to the React app it's also routing traffic to the proxy app and keeping it all on the one domain which is incredibly valuable because you then get the one domain and it's really nice for discovery that you'll see very shortly. I'll also cover a little bit later how that all kind of ties together. Cool, and let's just go for a quick demo. So I might just swap my screen sharing actually. Oh no, I don't need to. I'm doing the whole thing. Okay, so no aces up my sleeve. So we've got our Drupal test environment running with do a mummy theme. There's nothing too crazy here and then we can go into configuration and search API and see all our indexes. And so we're using Elasticsearch connector and the search API module to then index all our content in. So pretty standard at this point if you've used Elasticsearch before. And then on the other side we have our search results which is a very simple React app which is then using our style guide and I personally really want to know about the fiery chili sauce which then takes you back to the main site. So that's kind of the front of it all. So content editors can come in and then edit content on Drupal and then the display and how things are yeah, displayed to an end user can be infinite. But in this case it's search results. Now how does this all kind of come together? So you'll notice, you might notice here that you've got API v1 Elasticsearch. This is configurable. And what this gives us is a really nice discovery mechanism for being able to deploy or to wire up two projects, two environments together into one and then have our routing configuration work really nicely. In this case like web apps can just write that they want to connect to slash API v1 Elasticsearch for their search content versus having to I don't know if you've had to do it but in the past I've seen some really interesting janky setups that where people have had to do switch statements per environment where dev goes here, staging goes over here and prod goes over here and it's all kind of hard coded in the app itself which can get a bit tricky whereas at this stage with Skipper you can then configure your routing layer to then forward traffic internally to a separate application and kind of compose your front-end application and all the service dependencies that it has on it. The other thing to point out here is that this is all right now being driven by Elasticsearch in this demo this isn't prescriptive this is just demonstrating the feature and there's nothing stopping you from having the Drupal site also expose like a GraphQL endpoint and then having and then configuring it so it pops out on like API v1 content or API v1 GraphQL The other thing to point out is this isn't just like a one to one situation it's not just one Drupal to one Elasticsearch to one node front-end there's absolutely nothing stopping teams from then architecting and deploying separate applications and then including the same routing configuration and routing to the exact same Elasticsearch endpoint here so you really do get this really nice scalable from a development perspective scale-out approach for connecting up multiple front-ends to a single backend or a single service so I've hinted on a few things here but I kind of want to dive in a little bit more so and some of the key features that are actually enabling this kind of functionality so the first one is our package and deploy mechanisms so each one of those Drupal the Elasticsearch proxy and the node front-end those were all Skipper projects and applications and our package and deploy methodology is consistent across all three you run Skipper package Skipper deploy and then you can run that in CircleCI we've done quite a lot of getting started around that but our package and deploy approach is very flexible you can then deploy each one of these technologies in the exact same way which means that your teams are using the exact same tools and that's kind of demonstrated in this graph where you could have X number of development teams X number of projects and then you can kind of have very consistent tooling in how things are rolled out the other thing to point out is our configuration system for Skipper so before when we were talking about Drupal then connecting to Elasticsearch and the proxy app connecting to Elasticsearch that's all through the one configuration system and I spent a lot of time on this architecting configuration system blog post I highly recommend you give it a read if you're interested it covers our configuration system how we expose database credentials connections to Elasticsearch and salt tokens and things like that it exposes all that information to the application in what we think is a very scalable flexible way for applications and in this blog post we kind of compare the other cloud providers and kind of point out how they do it as well the other one is declarative routing so I might just quickly skip back for a second you might have noticed that there was no cloud front here the proxy app there is for React and there is for Drupal every single one of our project environments so that's dev staging prod they all get dedicated cloud front environments but sometimes you don't want a dedicated cloud front environment for your application you don't want it exposed to the public in a discoverable way so in this example actually maybe another use case is you've got a bit of cloudflare or you've got section.io or you've got like you've got external CDM providers and you want to turn this off and then use your CDM provider so what we have is the ability to go external so you can set your ingress you can set your cloud front to external and then you can just connect to the load balancer and use that but what that means in this case is that our Node.js app connects through directly to the proxy app versus having to go all the way back out and through cloud front and all the way through and that is configured using the following configuration so so any app like we have a very robust proxy configuration this example is just using an internal project as a target so so here we're saying our API is API v1 Elastic Search and we're routing it through to the production environment with the project Elastic Search but we have other configuration on top of this so for this example this is an internal project if this was an external endpoint we can target that instead we can target HTTPS colon slash api.example.com or something to that effect so it's very robust in that way and that sort of brings it all into one place so you can declare your routing and declare your dependencies on other projects. So if you'd like to learn a bit more about this all the code for each three project is open source so you can go and judge me on how I deployed Drupal and Node specifically Node I'd like to know what people think about that but this is a very fun experiment and if you want to get to know the anatomy of a Skipper project this is a good place to look we're going to be investing a lot of time in the future around this repository to then demonstrate how certain types of apps can be deployed and run on Skipper but also our blog post we're pushing out a blog post every two weeks to a month at this point so and there's still a couple more to land this year including a blog post about our Node.js like that Node.js app and how to deploy Node onto Skipper as well as an announcement for a webinar and sort of the first half of next year that kind of deep dives into this topic a bit further we're kind of sitting at the high level architecture right here we'll do a demo which is much more deeper into the Skipper command line and deploying these projects and I just want to flag our friends over at NSW Gov who have been really great partners to work with especially around the Elasticsearch feature that we pointed out so and I hope you went and saw their talk if you haven't go check out the video when they come out but that's me has anybody got any questions that was a lot of content not for Griff if you thought about any you know cool Hi buddy cool well if people don't have any questions maybe we can gift the gift of 12 minutes back to folks oh okay Nick Sanamaria for your Elasticsearch setup would that work in a multi-tenant environment yes absolutely so each environment gets a prefix so you can do prefixing for that via project name and environment name so then you can absolutely do multi-tenant and the RBAC system that OpenSearch has is really really nice so we have a bunch of Kubernetes controllers which then take a configuration and then apply it to the Elasticsearch instances and in that case you can you can limit it right down to actually it was a real interesting time trying to debug that because we started from a place of you can't do anything to a place of oh you can write to the index you can create indexes like with this prefix oh wait no you need bulk write permissions okay we'll give you that so we slowly added to it as we went so it's so it would absolutely work for a multi-tenant environment at least from a permissions standpoint yes yeah and then sorry in terms of the proxy app too so I'm just pulling that thread a bit more in terms of the proxy app you can deploy as many of those as you like so there can be one for dev staging production that then only has access to certain indexes that was a very key piece here was that the proxy app we wanted to use the proxy app because it holds identity which then means we can assign RBAC rules to it to say you can only access this set of set of indices so or indexes so um yeah that was super important and that's all just read only I can put you on the spot I can ask you a question that we haven't prepared I was just going to ask you if there's anything you'd probably want to speak to about skipper or you know that offering that we could you know use in the university space that would be useful in that sort of market yeah for sure um yeah pulling pulling at that thread I think there's two things I think that sort of centralized search is well there yeah there's a few things but the centralized search is a pretty key thing for for Unis so we see a lot of clients building a standard profile for Drupal and then deploying that out skipper can do that it's proven itself you can run many many many sites on a skipper platform but but having elastic search at the heart and then indexing all the content in there and exposing it in that way that's that's something I think in that case would would work really well um yeah yeah yeah I think that's kind of the the big one there um yeah it just just depends how they slice it it really is kind of that like multiple sites single search so kind of like what Santa said with Nick San Maria said with the elastic search setup for multi-tenant but you could do it where yeah you have like the search app grabs all the content from all the sites that's indexed and then surfaces it out and then they can kind of discover all their separate Unis sites in that yeah there's a lot of like clients I'm working with that have maybe a current student site that's built separately that's on Drupal 7 and their main site might be just recently upgraded to Drupal 9 and they want to index content from a you know a curriculum website and and things like that so it's good to hear that this can support that yeah for sure um I think the other one is surfacing endpoints or surfacing services so that routing configuration like I said points to a like a skip a project in an environment but um the other thing is you can like I said you can point to other endpoints other HTTP endpoints and we've seen other clients use it for surfacing and other services like a booking service or something to that extent so you can just go slash booking and then not have to go to a completely different URL so so there's little things like that as well that can can really benefit Unis because they do have a lot of services they do have a lot of a lot of moving parts to have to deal with great yeah this sounds good I wish I had a question for you buddy well thanks everyone for coming this has been the previous next and skipper showcase thumbs up