 Welcome everyone, this is a session about our new website from Bonn. And let me control the slides in a different way. And we will have two parts of this session. In the first half, we'll have Ben, the general manager from Bonn, to talk about customer delivery. Then in the second half, I will talk about the Drupal solution. Now it's all yours Ben. Thank you Josh, if we can go to the next one. Probably just want to introduce this presentation with a little bit about the why, and in particular why it was so important to get customers involved in the first part of the process. So if you don't already know, the Bureau of Meteorology is one of the most used websites in Australia. Our brand is one of the most trusted and reliable brands that provide weather, water and climate and ocean services to a broad range of customers. Not only the Australian community, the people on the street but also quite sophisticated customers, either in industry or in sort of other government agencies. And I'm sure that there's a lot of audience members that use our website for this or use Bureau for this. The most common way that our customers and the most I suppose the biggest coverage way that customers receive all this information is through our website. Our website's been there for a long period of time and I'm sure all of you guys are probably smiling and seeing sort of all the great things that our website does today. But that's sort of one of the most important ways that we get to transmit and inform our customers about key services and products that we do have. Just moving on to the next one. Josh, please. Okay, cool. So on the right hand side there, a lot of you might sort of see the common pages that you have on our website today. So many different styles, many different designs, many different ways to find information via our website. And it's really quite inconsistent from an experience perspective. Obviously, because it's been built organically over a number of years, it's been built in a way that does have some vulnerabilities in it with stability and resilience. And it's actually not intuitive at all. One of our biggest findings from our customer research was that our customers have reams and reams or files of bookmarks which they go to to almost navigate to different sections of the website. So it's been there for a while and it's served its purpose and it will continue to serve its purpose but not in its current format and current looking field. I mean, we have sort of close to over 100 million hits on the website per annum, a large amount of... If you should depend on who you're talking to, it's one of the top 15 websites that are hit in all of Australia. It's two thirds more traffic than any of our government agency peers. So it's quite a popular website. Funny enough though, if you look at the website, there's probably about only 15% of some of the information in there that's hit 96% of the time. And no guessing that that's sort of, you know, in particular the radar. It's one of our most popular features. It's one of our biggest branding issues that we've got with the Bureau. We will continue to sort of have that sort of branding moving forward. So what are we moving to? And why? Next one, Josh, thanks. So our customers, what would they tell us? They wanted a more simple, modern way of looking for information and finding information on our website. We know that the radar and our mapping is almost like a cop, has a cop following to it. However, though, we know just from a consumer perspective, the way that you navigate and look for information on a map has changed dramatically. And you know, this is not us changing it, but the looks, the likes of, you know, Google Maps and Apple and the way that you sort of look and direct. So we need to sort of also increase our standards today to make sure that we meet those types of expectations. Improve navigation. So our current website is almost departmental based, i.e., you know, we have an aviation department or we have a water department and then you go into that. We've moved that around to make sure that it's architectural based, archetype based. So what are customers jobs to be done? And what are the most common things that they will need to find to do their job? So it's a bit of a shift in the way that the navigations go into navigate, the way that the new websites can navigate. Our South Service Portal is an interesting one because we've got a whole range of customers, as I mentioned before, to sort of small to medium-sized enterprises all the way up to quite important and large industries. But what we need to have is as much self-servicing as possible on the website because we just don't have that workforce to have one sort of met or one forecast for every customer. So it's really making sure, really uplifting the new experience about servicing their needs through our South Service Portal. And because we're moving to a modern architecture and API-led architecture, we'll find better ways to share in data and obviously sitting on a quite a robust cloud native sort of infrastructure as well. Next one. So what can you expect from our delivery process? And I sort of hear you talking a little bit about or mostly about the upfront process of designing or co-designing the look and feel on the website with our customers. And obviously that's a really big theme as part of the DTA delivery process that we all, it is all good practice to utilize to deliver to. In addition to that, comprehensive customer discovery phase which has been going on now for over 12 months was a key element to that and also delivering incrementally. So we've got MVP that's coming out early next year and then we'll start and then from there we'll sort of incrementally deliver more features as we go until we sort of get the whole website transitioned across. So it's been quite exciting up until now. I think we're in the heavy build and just about to go into sit testing for some of those MVP features and really looking forward to the next phase and really looking forward to launching this really new look and feel next year. But I'll hand over to Josh and he can tell you a little bit more about sort of the underlying tech that we're using. I'm here myself. Thanks Ben. All right, let me jump to my slides. For anyone who doesn't really know me, I'm Josh and the solution architect from Accenture. Accenture has been selected by the Bureau as a delivery partner in this really exciting journey. We selected Drupal, mainly based on the three reasons. Drupal has been really popular in the government. There are a large number of Drupal websites in our student public sector and a big part of it is Dupal Synapse Client. And now we do that at Gunstom S. We do leverage from Gunstom S module and call review process to be able to do our module shopping. And Drupal offers huge flexibility that we allowed our content author or Synapse admin to be able to create a really complicated layout or landing pages from the UI. And also Drupal offers its feasible entities that we leverage from the field to allow the content author to be able to configure particular paragraphs or widgets. And Drupal is open source. That means that it's free licensing. We are actually leveraging from the really large global level of support from the security level and from the module and the code level, of course, from the local Drupal community as well. Okay, we are using a progressively decoupled architecture for anyone who doesn't really know what it is. Architecture, I'll just give you a brief. And this means that we embed our React component and our React application into the Drupal theme layer and we deliver the React application to the browser via the CDN. Each React component itself has its own logic and it can actually contact any external API services via the API gateway. In this way, we have less traffic from the browser to Drupal. We chose this architecture mainly from three perspectives. From the performance perspective, we try to minimize the traffic between the browser and our web server, giving that huge amount of weather data are required in the user's browsers. So we try to leverage the traffic between the browser and the gateway from the bureau straight away. In this way, we don't have a really high number of traffic directly coming to our web server, so we can protect our web server better. And from the developer experience perspective, I'm pretty sure you all know that it's pretty hard to actually find a good Drupal developer in the market. It's even harder to actually find a developer who knows React and Drupal in the market. But with that said, if you become one of those, come to talk to me, let's have a coffee. So that we try to have our dedicated team only focusing on what they're good at. So we have a dedicated React team. We have a dedicated Drupal team. React team doesn't really have any knowledge about Drupal framework. And Drupal team doesn't really know anything to do with the React framework. What we do is React team can focus on their own education development. Once they are done, we embed the artifacts into Drupal theme layer, and we tell the Drupal developer which are the props. How do you configure the React component? So that our website can be built with blocks, paragraphs with all the fields, then we can pass the field value to React. Lastly, from the components reusable perspective, all the paragraph types are reusable and available in all the content types globally in our website. And React components is independently available for any other React application to use directly. In this way, that we can reuse the entities that we create in this project in two perspectives, from the front end and from the back end. As I mentioned, we are building a really, really React heavy website with Drupal. So I will talk about how did we use React in Drupal from three points, the Bureau's design system and the widget we built and prioritization. The Bureau has its own design system. What is the design system? Design system is a collection of components that defines the look and feel for the digital product. The Bureau has a requirement to have all the digital products from the Bureau to follow this design system. This design system is developed in React framework. That means that when we create our Bureau's website, we need to use those React components in our website. The way that we use the React components in our website is that similar to the DTA pancake library, if you know that, as you remember in the old time, we created a custom JavaScript library to actually wrap the components made by React. That wrapper will be able to actually expose the HTML markup into the tweet, so that when our theme in our quickbar dump in an HTML markup, then our library will know, okay, we need to load these particular devices and components into HTML. In this way, React is embedded in there. With that said, the Bureau has its own app, Bonweather, is using the same design system as well. If you are not using that, try that. I'm pretty sure that's better than other better than that. So far, we've created about 80 widgets. Using the Drupal terminology is 80 paragraphs times. We're using the paragraphs to represent the widget. The way that we embed the Bureau's design system components into paragraph template is that, as I said, we use a React library and we put the HTML markup into the tweetbar. In the property of the D, we tell the library which component, what is component name we're going to use and the following the particular markup that we will actually load the components into the page. And using the paragraph with a lot of fields, we allow the content author to be able to actually pass in any parameters and then our theme will actually pass the value of that parameter to the prof in React. In this way, we can create unlimited number or versions of widgets in each page. I'm listing like three examples of the widget we're creating here. As you see, there are really simple one, the static one, like the link list that we use the design systems. Oh, sure, only five minutes. Yes. All right, I got it. All right, I'll speed up. So then we have a math and already forecast that's more complicated that we actually grab the forecast and observation data from the Bureau's API. The logic is handled within the widget in React. We are on the journey of personalization. The Bureau will keep continue offer the personalized service to different groups of audience starting from their homepage. If you are the first time visitor in your homepage, you will see they actually they forecast details and observation detail and warning details for the major city. But you can actually set up your favorite location in the site and then we save it in the cookie. When you come back next time, we will actually load all the details with the details of your favorite locations. So this as a start, we will keep learning from our user behavior on the website. We actually integrate third party services in Google. Alchemy is our CDN. And we, of course, we use Alchemy and purge to dynamically purge the page. Once the page is updated by the content author, we use followback as a search engine to be able to actually return multiple websites search results. When we are in the transition period, we will have the new and the old website running in parallel. And React components is interacting with followback API independently. We use Google Tech Manager to actually learn from the user behavior. And we use the ID management to be able to allow the external user and internal user in theater to be able to log into the websites using their own credentials. I'm not allowed to tell the details about ID management due to security reasons. And the website is hosted in private cloud using infrastructure as code. And we do have the latest technology to design the CI CD pipeline for dedicated React and Drupal team. Of course, we have a high percentage of the automated test. I think I just rushed to the end. This is my contact and Ben's contact if you have any questions. But I assume we have a couple of minutes left and we're happy to take any questions. I can put in the questions now, Josh. The first question is, how do you manage routes and paths? Are they served in Drupal or are they served in React? Sorry, how do we manage which? Routes and paths. It's in Drupal. So we define our own path in Drupal and Drupal is able to be able to tell which React components to load in which page based on the URL. Then there is another one which says, is the personalization done Drupal site or front end? At the moment, it's done in Drupal site but in future, this is a possibility that we will do it in front-end. What mix of front-end, back-end frameworks are you moving to in terms of JS frameworks, etc.? I'm not sure about these questions but we relay on the React framework and in future, we'll continue working in React framework. There's another one. Is there a pop-in load effect? Do you have any SSR, SSG in React? I can't really see the question. Where is the question? It's in the live Q&A. Live Q&A? No. We do not really have the SSR, SSG but we do have some pop-in load effect but it's all dependent on the USC. So as we continue developing the new website, there will be new USC coming up. And probably the last one. Can you touch on Borm as a provider of data to other agencies, consumers and how that works? Fantastic question. That's Ben's question. Yeah, we have six seconds but yes, we are currently working mainly on the data to data type element but moving forward would be more API based share technology for sharing data between not only other agencies but also third party organisations as well. All right, it looks that that's the end of all the questions. Thanks a lot and it was an awesome presentation. Bye. Thanks all. Bye.