 Welcome everyone. We're here to talk about components of a component today. Just a quick introduction about me. My name is Nathan. I work for the Department of Customer Service for the OneCX program. Anyone who's not aware of that, that's 750 odd NSW government websites being rolled into one single Drupal instance. I've been working with Drupal for 17 years I think. I think my first Drupal migration was Drupal 4 to 5. And I'm mostly infrastructure and backend. There's other people in this room that work for DCS as well. They will vouch for the fact that I cannot write a single line of react. So just quickly some context for this discussion. Today we're talking about a component in the sense of what you'd find in a design system. So this is not a Drupal 10 component like the components module that does one directory of everything. Or similar. It's not component like paragraphs or layout builder. It's not a component like a capacitor in an amplifier. This is the design system components and that's just about styling and how it displays on the screen. So let's go into how people think this works. Someone comes up with an idea. Someone like me builds it and it goes live on the website. Everyone's happy. Components released to the website are all good and dusted. But no. We are the New South Wales Government website. It takes a lot more work for a component than that. So let's go through how it actually works. So here's a workflow diagram of the steps we go through to build a component. Hopefully you saw the last one started with an idea. This one hopefully in your case starts with a problem. Something that actually needs solving first. The next step is the idea going with the design team and working out how we're going to solve that problem. There's the design itself. So we use Figma working out the design, building the design, that kind of stuff. It goes to a working group. So the designers have come up with a couple of ideas. They go to a working group. They talk about that working group. They work out what the best design for us is going to be to solve the problem. The design then goes through user testing and gets refined and checked and updated and whatever needs to happen. And then finally it goes to approval. That's six steps already and we haven't actually got to building it yet. There's content modeling. So how does that design then fit into the website's content model? Can we reuse what we have? Do we need to build something new? Do we have to add new features? We have to go through that analytics team. Work out what kind of things they want to track for that component. Personalization team. What parts of that component are going to get personalized? How do we want to use it specifically for users? And then finally solution design. So we've got all that information now. We know how to do personalization. We know how to do analytics. We know how it maps to our content model. We've got a design we've used to test it. We can finally work out how we're actually going to build it. The next step, build it. So the Drupal component that we talked about before. The one directory Twig HTML CSS. How that maps into paragraphs. How that maps into block content. Building a React component as well because basically we have one-for-one parity with everything React and Twig so that we can build apps in both. Unit testing. The style guide itself. Doing functional testing on that component so that we know it doesn't break over time. Automated visual testing so that when we make a change we don't break other parts of the site. Actually confirming our accessibility testing making sure that the thing we built and got all checked in the first place actually works the way we expected it to. Building training modules. Writing documentation. And then finally we get to go live. But we'll go into a bit more detail. Specifically on the Drupal side we're going to talk about these things. Personalization, analytics, content modeling how we do them. I will take questions at the end but this is how the New South Wales Government does it and how we get the best out of our teams. It may or may not work for you but I'll just go through the process. Content modeling. So we've got a semantic content model. What I mean by that is we've got this design component that shows links on a web page but we've got six or seven design components that show links on the web page. The content model just tells the editor I want links on a web page. At this point I don't care how it looks I just care that I want links. So they build that first and then they change the style and they pick the different components from the library on how they want it to display based on the use case. We have landing pages and we have campaign pages and we have standard pages. The content model doesn't necessarily match. So an example would be that on a campaign page you're allowed three cards in a slider. On a standard page you're allowed two cards and that is it. And that comes down to how our content team wants to work and how our UX team wants to work so we have to design that into the system. Our database is crazy. For perspective we have 1300 tables. Our revision table has 10 million records in it. So when someone says I want to add a new field to a new component then it matters. So we have to care about are we reusing our fields across our content model how are we reusing them, where are we using them how do they fit into the design that this editor designer has come up with. And I'm having a bit of trouble with live demo so I have to jump out of this. So hopefully it doesn't flicker too much. But just as an example what we've got obviously is the banner we've got links but then we've got this hero search component we've got the links on the website in a three column layout we have this featured component then we have featured news which has kind of this left hand side featured news article right hand side and there are more links and this profile of the premiere these are all separate components on the site they're put together with layout builder users do what they want to do the goal is just to get them to this point where they can compose the pages they need to, that kind of stuff so let me just jump back actually maybe that works better can everyone see that okay and then I don't have to do the stuffing around analytics so when I said before we have to discuss with the analytics team what they want to track the analytics team knows better than we do about all the different stuff that their users want to see and do so rather than us as solution designers coming up with well we want to track that action or this other action we obviously go to the analytics team and say hey what do you want to have a look at on the page that's not working either I don't have my notes now cancel that come on so we go to them we come up with this we have this data analytics component equals thing what we do is we add that to all of our components on the page the specific elements that we want to track and then we hook that up with the data layer when we're designing the component the as I said this is not working for me let's go have a look so we have a development tool here you can see the yellow outlines on the site there that is all the parts of the component that the analytics team have asked to track so we have development tools that say whenever you see this in the HTML structure let's mark it up you can see they want to track accordions they want to track the keyword search they want to track the links here they want to track the tabs that are moving across they actually want to track how many results that the user got so what we do is we mark it all up with this HTML structure so that we can just quickly and I think Jess yesterday for saying integration tests are the best type of tests we can just have a look at the page when we're testing it and go show me all the things that are tracking on that page and you can see it like apply filters button clear all button all that kind of tracking one thing I did note and I'll call this out to Ken who's sitting over there when I was doing this testing this buttons track but our language translation isn't that's probably something we have to fix so let's go back in here the next one is SEO and personalization this is similar so as I said we've got that component that generates links that shows links on the page wherever we need to the personalization team have ideas about what they want to personalize how they want to use it so as an example the events on the home page might change from the city of Sydney to a regional event when you're coming from a regional area so we do that with data attributes as well in this case it's data target equals the reason we do this is so that rather than the personalization team trying to go through the entire html structure find the element they want to change whatever they just go data target equals tag links they find that element and then they adjust the links and off you go the example for that because I like making the screen flicker is and from an SEO perspective because I forgot to talk about it a little bit earlier they also have things like the SEO team might ask for a bunch of attributes on the html that specifically outlines question and answer type formats for Google so that we get better results an example of that would be we've got this heading text with collapsible with text this actually has specific html markup on it which is a question and this has specific markup on it which is an answer so that when you get those Google search results at the top you know how it says you might be talking about and here's some questions all that stuff comes through that's getting put in the html structure by that personalization team an example of the personalization of tag links transport projects, how demerit points work things like that when you land on this driving, boating and transport page these are all personalized to you they're personalized to you based on whether you're local to New South Wales whether you're coming as a visitor whether you're a business person or a resident all that stuff is coming through the personalization engine another example would be try this page link so this link specifically has the data attribute on it so that the personalization team can adjust this link when you land on the page not found page based on your previous search history or where you are in the URL structure things like that so that's the SEO side of it let me go back into here page building I talked about it before we have we need to decide where and how a component gets used something like the e10 fuel filter that is specifically only for campaign pages so we'll only build it for campaign pages if it's something like an accordion we will build it for standard pages and landing pages and react apps so we go through and that's where paragraphs and block content comes through we have both and there are pros and cons as it says up here but the pros and cons are the fields are different the drop downs are different there's slight tweaks between the two depending on context and what we want the editors to be able to do the next one the style guide so this one I'm going to talk about a bit longer if you have any questions just ask me this style guide is kind of custom to our development process the best way to think about it is the setup in a PHP unit test as I said before Jess's talk yesterday integration tests are best so what we do is we have an entire process that builds a page programmatically as if a user was doing it but it does it as part of our build system so what I'm saying is that let's say we have a links component that has so you create some URLs you put it on a page and then you have variant one variant two so it styles slightly differently layouts like differently different backgrounds things like that we do all that with a PHP class and we programmed it such that if I change the PHP class when I push it through the build system the build system knows that the hash for the class has changed so it rebuilds the content page but it builds it in a way that it's actual editable content it's an actual piece of content on that site it gets all of the analytics it gets all the personalization it gets put through our search API it gets everything about it is done as if it's real content but we don't have to rely on user content that they change and break our tests we don't have to rely on that anymore so we build all this part of our testing system as I said it's programmatically created it's automated as part of CICD changes are detected and automatically upgraded to pages it doesn't rely on user content and now I'm going to do some demos so here's an example of cards on our star guide so you can see at the top here Drupal star guide a layout builder cards there's cards on here that have images there's cards on here there's cards with red lines on them and cards without red lines there's cards with what we call pictograms and you can see color changes and things like that on it we have white cards we have blue cards we have light blue cards and we have accent color cards and then we have all of the same cards on a grey background and the point of this is it's just a single page that takes that cards component that we talked about and puts it in every single possible combination that an editor could do so that we can test it an example of this is ID supports password checker I don't know if you've heard of this in the news but it just shows you your password strength based on some API calls but you can see we've got this on a white background and a light grey background and a dark blue background but this one here this would get called out because you can see just by looking at it that this line on a light blue background is an up to color contrast spec so that's why we do it designer would come and look at this page go through it all as part of their testing and go that specific instance I want you to make it black so that's the style guide just give me a second as I said because it's actual because it's actual Drupal entities they're editable by users if the QA needs to go in there they can go and make changes they want to make tests that things are working the system will detect that and rebuild it on the next merge request so it gets reset back the analytics team use the style guide so they go directly to the page and check that they're getting analytics on everything they need to the personalization team use the style guide so they go on and make sure their personalization scripts are working on the style guide the stakeholders themselves so one of the problems we had was every time we do a push to one of our branches it would rebuild our preview environment all that content we're messing with got deleted reset now we have a page we can save that page has your component on it and it always will forever go and have a look there and it just gets rebuilt so it saves a lot of development time and effort yeah that's the style guide next one is functional testing the next step of that is as I said the style guide is like PHP unit setup we do that because we have Cypress testing on the back of that to do all the functional testing and make sure it's working as expected but those pages are already there we can literally point Cypress at all of the style guide pages and say click this button click that button do that drop down make sure that things are working as they expect to we have moved to Cypress for transparency there's the QA team there's the personalization team there's the development team there's the analytics team and having your well in our case having all of our testing PHP unit meant that they're really hard to be transparent to all those teams with Cypress everyone can get all the results from Cypress Cloud and they know what page it was pointed to they know what the results look like they can see the videos QA can update the test development can update tests it's all fully open to everyone we have 450 tests at the moment that run across all of these style guide pages and just for those data boffins we have 450 tests run in 11 minutes across 6 concurrent threads so we just bump up the number of threads when it gets lower than 10 minutes and Cypress is we currently have a beta test it's a Cypress feature in beta at the moment which is for every single URL you hit with Cypress you can do the functional tests with accessibility results straight out of that without any additional work so we use those as well how am I going visual testing the style guide pages there's 200 of them with different components different settings we also use that to go well compared to the last release and now what has changed we know that the style guide exists in both it was built the same way it's not user content it doesn't change so we can literally do tests like this show me all the stuff that changed on that page as part of the release who broke that padding another one this stuff was at the top and now it's at the bottom why who broke things I've got a couple more slides DOD the best way I can describe the definition of done is that task you want to do but someone said you had to the training so the first one is we use we then have to go and create training so we create both LMS training style training with videos we also do live training as part of sessions with the training team on all the components that we create how to use them, how to edit them, where to use them that kind of stuff help hub so we then have to write documentation we have to write documentation for the editors like you can only use these type of links for this type of reference and technical documentation which I will quickly show you here so we do things this one's a little light on the analytics but it'll usually say why we're tracking which fields and why the HTML, the React component and what all the different attributes are to the React library and which Drupal library to include and we do that for all of these components cards, filters and down to the date the error, the field set that kind of stuff so that we can just point out and say go for it quickly next time I work out why PowerPoint doesn't let me just switch screens as I said it works for us this discussion wasn't a we do it this way you should too it was more about these are all the problems we had and this is how we solve them and hopefully it will give you something if you are experiencing some of these problems and ideas on how to solve those I'm around for the rest of the day so please come and talk to me if you have any questions and I'm on Slack as enter bot and the last one is questions do we have time for questions? live on the site at any one time there's about 40 to 50 editors there's about 300 user accounts on the site so what are you using for visual testing? how much of your personalization and those extra pieces and flan that you've got on your site because open source will share with you? so we do try and share everything back that we can so we'll go into building a component with the idea that the module behind it will go Dribblesource on Dribble.org one of the examples is data pipelines that we talked about last year where we can we do but we're kind of limited by being government so yeah things like we'll do improvements to modules that will help everyone and then we'll do a little bit of customization on top that we need to but our first point of call is to do it for open source first