 It's Thursday, we're almost there. I'm Joey Groh, Director of Creative Design at Phase Two. Phase Two is a digital agency where we work closely with our clients and we put experience at the forefront of what we do, whether it's for the customer, the user, or the patient. So today we're super excited to walk through how Phase Two and Northwell Health built a living style guide using Pattern Lab and how we ultimately integrated it with Drupal 8 platform. I'm joined today with Carly Cunningham and Pete Sanzone from Northwell and I'll let them introduce themselves. Hi everyone, so yes, I'm Peter Sanzone, I'm the Director of Technology at Northwell Health. My team oversees Northwell.edu, the Drupal implementation there and we're responsible for all the other public facing web properties that Northwell does. Hi everyone, I'm Carly Cunningham, I'm the Manager of User Experience also at Northwell Health. So to give everyone a quick idea about how this session is going to go, here's a quick overview. First I'm gonna speak a little bit about why it was important for us to invest the time and energy into building a digital style guide and how we made the case for it to our senior leadership. Then Joey from Phase Two is gonna talk a little bit about how we approached building a design system and what we accomplished. Then Pete's gonna talk a little bit about the implementation aspect of actually implementing the digital style guide into Drupal 8. And lastly we'll highlight some results and learnings before opening up the floor to any questions and conversation. So a brief overview of Northwell Health with the largest healthcare provider and private employer in New York State. We have 23 hospitals and nearly 15,000 physicians. Across our health system we see about 4.3 patients annually every single year through doctors' offices, emergency rooms, many types of different kinds of treatment facilities. We're much more than just a large organization taking care of people when they're sick. Through our Feinstein Institute for Medical Research we're pioneering medical discoveries and leading on the front of medical research. At the School of Medicine in partnership with Hofstra University we're training the future generations of medical professionals. And with our Northwell Ventures Division we're developing breakthroughs through innovation which are changing people's lives. While Joey and Pete are gonna talk a little bit about how we created our digital style guide in Pattern Lab, I'm first gonna speak a little bit about why it was important for Northwell Health to invest in creating design standards. In 2016 we changed our name from Long Island Jewish Health System to Northwell Health so it rolls off the tongue a little bit better. This transformation came with a new logo and a really vibrant color palette which represents our brand's diversity. All of this came to our design teams for the first time three months before we needed to go live representing our brand across numerous different digital platforms and thousands of web pages. The real trouble we found was that these guidelines we received from the agency were created for print materials and it didn't take into account user experience or usability in the digital space. So we knew we had a problem. While we were able to accomplish the unimaginable applying these guidelines across multiple sites and thousands of web pages in such a short timeframe, what we ended up with were inconsistent design patterns and major usability concerns. Another big challenge we had is that many of our websites are managed by separate design teams that have very little, if any, connection at all to one another. So each team interpreted the brand's guidelines differently in their digital application. Here you can see a few of the numerous different Northwell websites each with their own take on applying the brand. At the beginning of 2017, with our brand still being very young, we knew we needed to make a change. But how are we going to make the case to senior leadership that these issues were serious, that they needed to be fixed and that they would inevitably hinder our digital growth in the years to come? We started out by building an interface inventory and if you've ever been involved in a content migration of a website before, if you've ever been involved in a website redesign before, you're probably familiar with a content inventory. Content inventories take stock of all of a website's content and an interface inventory is very similar to that only instead of sifting through and categorizing content, you're taking stock and categorizing the individual bits and pieces that make up your website. Here you can see a couple of the different examples for buttons and links that we were collecting. There was a multiple pages of different buttons and links. This is only one shot of each of them. So you can see that it was, there was no real pattern in them. You can Google Brad Frost if you want to learn more about how to do an interface inventory. So what we wound up with after completing that was a document that had more than 80 pages highlighting all of the different types of elements and components and along with their stark inconsistencies. Here's a few more examples from our interface inventory. While deconstructing and cataloging our website's parts was certainly a tedious process. The results were extremely beneficial. The interface inventory laid the groundwork for building a sound design system for Northwell. We knew that we wanted to create a systematic atomic style guide driven design and the interface inventory helped us deconstruct pages down to their atomic levels so that we had a starting point. If you need to convince your organization that establishing a cohesive design system is essential, like we did, an interface inventory is your first step. This is especially true for really large organizations like Northwell Health that consist of many teams who work with multiple third party agencies. This was one of the biggest ways we got the buy-in that we needed from senior leadership. That we had the way we had the buy-in from senior leadership and showed that we had a problem. The interface inventory promotes consistency, displaying a variety of similar but still different treatments next to each other, exposed redundancy and underscored the need to create a consistent cohesive experience. We then performed a usability audit across multiple Northwell websites using the 10 usability heuristics for user interface design. This helped us quantify and show our stakeholders in a meaningful way the UI issues that needed to be addressed in the design standards project. We were able to categorize them into near-term, mid-term, and long-term with about 70% of all of the issues being something that the design standards initiative would be able to address. We also performed an accessibility audit across all of our websites. As a leader in the healthcare space, we have a mandate not only legally but morally to have a fully accessible website for visitors with disabilities. And that's not something we take lightly. So we identified numerous ways in which our site was not fully accessible and that was not okay. So now armed with those three things, the interface inventory, the usability and accessibility audits, all of that effort led us to get the investment we needed to create the design standards initiative. This is where we partnered with phase two to standardize our design system, create flexible, accessible components and implement a living style guide. It was important for an organization of RSI's who works with multiple vendors and has multiple different areas of design that are not connected to have a design system that's documented for reference, so we're all speaking the same language. Our internal design team is very, very small and our business needs are constantly changing per project, so we needed a way to be able to design more quickly and efficiently and by having a shelf of reusable components, we were able to do that. You don't need to reinvent the wheel every single time there's a new design ask and if you don't have to do that, in the end you're gonna save time and money and the same applies to development. When the smaller parts have already been built there's less effort to assemble them in just a different way. By establishing a common language both upon usability and accessibility best practices we can now focus on improving what exists instead of having to create something new every single time there's a design ask. And having a library of reusable components has allowed us to train our larger marketing team who are not designers, how to assemble pages for our clients which are our doctors in our hospitals. So now I'm gonna pass it up to Joey who's gonna talk a little bit about how we actually built the design system. All right, so now we get to build it. So as we work through a proliferation of inconsistent elements just across so many digital properties we sought to craft a design system that exemplified continuity and reusability. So in order to help us we wanted a vehicle for our design to development process using a common language and tool. So we chose PatternLab and the atomic design methodology that's baked into it. Created by Brad Frost and Dave Olson you heard Brad Frost earlier. PatternLab is a component inventory prototyping system that includes a style guide framework the output of which is created by a static site generator. PatternLab would also integrate with their Drupal 8 platform in the future so in a very elegant way you'll hear more from that later on from Pete. All right, so atomic design concept don't know it based on chemistry basically breaking elements down into their smallest constituent elements. Atoms make up the smallest pieces consistent with things like labels, input fields and buttons combine them together and we get molecules. A search form example in this instance continuing to combine atoms and molecules together we get more complex components called organisms. The components would use production ready code and be context unaware filling up their container so that way they can be used in a wide array of layouts each with their own responsive behavior. So here's a screenshot of PatternLab out of the box. It does come with a navigation structure for looking through the atomic elements. You can also set up templates and pages where we can prototype out high fidelity HTML pages as needed. PatternLab does come with a style guide but for our purposes we wanted to provide a curated branded version which is custom designed for site admins and builders to consume. So if you're interested, check out patternlab.io for more information on that. So the living style guide would integrate with PatternLab using the same components but organized with variants and usage texts in a bit of a friendlier user interface. So as helpful as the style guide would be we still wanted people to be able to get to PatternLab so we included a link at the top there. So with PatternLab, atomic design and a structure for our curated living style guide we were ready to continue on with our process. So on the heels of the work done on the interface inventory, we had this all day session and we printed out every component and example we could find and we were going to the printer and getting stuff and oh this side, this side over there and we grouped them into all these like categories and put them on the wall. We just really wanted to see and be in burst with the current state of things and it just kept going and went into the evening and eventually we got kicked out of the room because another meeting was coming so we went into the hallway which is out there by the design bullpen so everybody was popping around to see what's going on like just such great energy and being able to see all of this together out there. So once we had it all on the wall there we started to go through each of these different groupings. We wanted to address things like brand expression, did the component fit in with the whole? Did it provide the best visual language for the North Pole brand? Usability concerns, we brought in user feedback and data that was collected prior to the workshop, front-end content model. Want to make sure that the components have all the right fields that we need to support the various types of content. And style of variance, each component could look a little bit different based on the content or the theme style so ultimately we ended up with some really great data, best examples in each grouping and then we had detailed notes and that prepared us to move on to the next stage. So now that we had some distilled output from the previous stage to work with, we started redesigning each of the components in the sketch design tool. We intended for them, for the static designs to help move the process forward, not really focus on them as deliverables themselves but really just taking us closer to get into the web which is ultimately, and the browser, the medium of the web. So over a few months, we cycled through batches of components each week making sure to, the designs were robust enough to address the needs of the various types of content. It's kind of hard to see on the screen here but there's some different sizes for the designs. We wanted to make sure that we also defined as much of the responsive behavior as we could prior to prototyping but sometimes it also happened in parallel when needed. We also wanted to make sure that the brand expression and the visual language across all the elements was consistent, this is just a small sampling of some of the pieces on there but throughout everything that we did, we really wanted to keep usability, accessibility at the forefront of our efforts. Just wanted to ensure that these interaction conventions were emerging, that people will understand how to use the site. We ended up having like a blue link color that's everything that's actionable is gonna be blue and so I wanted to be really careful about that from some of the pitfalls that we had before with how the brand expression color titles and things like that. So by the end of the design and prototyping phase, we're pretty much iterating completely in the browser transitioning to production-ready HTML, CSS and JavaScript. Here's a few examples of some of the output in the Libyan style guide and we'll share the link later on if you wanna check it out and I'm gonna pass it over to Pete to talk about how we implemented the design standards. All right, so resetting the stage for a second here. This was about March, April, 2017, all this work. It was coming to an end. We had Pattern Lab in construction. It was nearly complete, so we had HTML, we had JavaScript, we had CSS being developed at a production level. The first challenge when we sat down with the UX team and discussed how we were gonna implement this in our CMS, we were on Drupal 7 at the time. We had an existing site that we wanted to rebrand using the standards components, the digital standards components, that the change was with the DSI or Digital Standards Initiative was that everything was now component-based design. So actually, I'll jump back a little bit to some of these. So these were components that were segments and stacked on top of each other within our website. Our current content model didn't support that. We had a traditional Drupal 7 build. We had content types that reflected our current content types on the website. So as a health system, we had condition pages, we had treatment pages, we had location pages, which were fielded and we couldn't really plug these into the new design the way we wanted to because they were component-based. So we wanted the flexibility, we wanted to interchange them and the fields on the content types didn't really work. So we kinda had a look at our content model and decide how we wanted to apply component-based design to Drupal in the back. What we came up with was a content model that was modular in and of itself. And we call it content patterns. It's basically a data container that's fieldable. So we decided to make these content types primarily for some advantages, which I'll talk about a little later. So they're not like custom entities or anything like that. But with these content patterns, we're allowed to contain the data so that when we put the displays, when we assemble a page, we can inject the data at the component level instead of having a condition page, which just has fields that a site builder has to fill out. Going through each of, going through this content revision was great and we came up with a long-term plan to migrate. It was on my work slate to move to Drupal 8 in 2018. So we looked at migrating the content over time. We had a great plan. We were gonna start development for D8 in 2018 with the new model. We were gonna apply the DSI standards. And when we presented this to our management team, they said, great, but you haven't till August to get this done. The reason being was because we had a large marketing campaign going into the market for our pediatrics department and our children's hospital. They saw all the wonderful work that we were doing to standardize our brand digitally and they wanted it. And they wanted it for August. So our wonderful eight month to 10 month plan to roll this out slowly became, we gotta get this done in the next couple of months. So what did that mean we have to do? That mean we needed to learn Drupal 8. And the reason why we went with Drupal 8 over implementing it in D7 is, as I said, we had this new content model that required a migration regardless. So the question was, do we migrate content, the current content types to the new content model in Drupal 7? And then later on in 2018, do the whole migration over again into Drupal 8? And I'm sure there's ways we could have streamlined that or do we go for Drupal 8? Based on some of the pros and cons in a lot of the conversations, we realized Drupal 8 was the way to go. However, that means we have to learn a new structure because Drupal 8, as folks know, I'm assuming doing the migration themselves know that Drupal 7, Drupal 8, it's not exactly clean migration in. We couldn't do, because we had the August deadline, we couldn't do a big bang. We couldn't relaunch northwell.edu with the new look and feel. So we had to have a stage migration or a phase migration. The children's hospital and the pediatrics had to go live first. They had to exist in the same vein with our D7 site. Our backend, we have a robust web services backend that powers a lot of our websites. They then had to become aware of the fact that we had a Drupal 7 site and we had a Drupal 8 site. We also played some tricks with a content delivery network that allows us to keep northwell.edu as our primary domain and route to the different D7 or D8 sites based on the URL. So we didn't have to play anything with having different domains. The new content approach though was key because it allowed us to provide content in a very flexible way and a modular way that allowed content by itself to be reused. So when you assemble components, you can place content within it that's decoupled and you can edit that in a single place and it affects all the places where that content's used. Just a little example, just to go back to the slide. So the content pattern here contains the image, the title, the byline, the description, taxonomy, call to action and that allows us to then distribute it to the way the components displayed. And the fact that we separated these allows us to control the display layer on the component side. So what does this look like in Drupal 8? It's not too much black magic. We use, so patterns, those content patterns I talked about are content types. Some of the things, the reason why we went with content types instead of custom entities were the facts that we got to take care or take advantage of revisions. So these patterns are revisionable. There are also, we can control them with permissions without any additional work. Again, these do not have a visual display. They don't translate into a page on the website. Components are paragraphs. So we're using the paragraphs modules to replicate one for one, our components in the style guide to render out on the page. We do have two master content types, component page and dynamic list page. These are the building blocks of our website. These do translate into pages. And that's where we assemble the components on that page or assemble the paragraphs on that page for rendering. Pattern lab does have different flavors and there's different ways you can start it. One of those flavors or one of the starter kits is a twig based template. So that allows us to pull these into the Drupal layer and reference those twig templates directly. We do that through a module called the component library module it's developed by phase two as part of this workflow. What that does is it makes Drupal aware of the namespace for the twig templates that are in pattern lab so that we can reference them in our Drupal 8th inning layer. It's actually really nice because then we actually embed pattern lab the whole application into our Drupal theme. And then through the Drupal themes we can reference the twig templates inside pattern lab and pull them directly in and we're just passing data down. Here's an example and I apologize for the crude mockups here but this is an example of the site builder experience. So if on the right side here we have a site builder they want to assemble a page that looks like this with our vertical components or horizontal components vertically. The site builder goes in they build a component page they go to the content section they add the components they want their settings and configuration for each paragraph there where they can inject the content they can decide the display layer do they want the blue background do they want the image on the right they can all define it there and then it basically gets pulled in and assembled there on the right. Gives that kind of Lego building block experience for our content editors and site builders and what's nice is because the content is decoupled the content is injected for each one so that's another element another like reference for all those fields to be filled in and maintained separately. So you can reuse for example if the top level hero is a link to another section of our website the image that's used there the title that's used there the description and the call to action is stored separately so that you can you only have to go to that one place to change it and we can do this hero banner across the site and not have to worry about adding those fields each time you want to use a reference to this content. Here's an example of like twig and the wiring in I guess and how it works. So we have a paragraph for example a hero carousel or hero promo at the top it references the paragraph twig template that's the standard in Drupal that's how you tell Drupal how you want your paragraph template to render all that really does for us though is provide the hook into our pattern lab repository so it really acts as a pass through we reference the twig template directly in pattern lab for how we want to render so we usually start at the organism level and work our way down depending on how flexible this component is and if we have a corresponding build of it in pattern lab sometimes it's as easy as just saying I want to use this organism in pattern lab and it renders exactly as is also opens up our front end developers to just purely work in pattern lab and they just work there and then these flow directly into our Drupal theme which then gives the Drupal the backend developers just to wire it up. One thing that's important to notice too is once you're in pattern lab you can then stay within pattern lab so you can go down into the molecules and down into the atoms and pull all those templates in makes it really easy to keep the theming in pattern lab and just a quick note for any sort of like data transformation or any sort of massaging that we needed to do of the data we do that all pre-processed so that the data flow down into the theme is really just the end result data that gets passed down through the templating stack. In the end, a couple of takeaways that we had doing this process we did end up creating a flexible layout system for our site builders. They create component pages or dynamic list pages they can inject the components they can move them around as they need for whatever marketing initiatives they need to replicate on the page. Pattern lab not only acts as our living style guide which includes browsable HTML code references to CSS and styling and JavaScript but it also acts as the direct input into our theming layer. The front end developers can work exclusively in pattern lab if they need to they don't need to know really much about Drupal. It kind of empowers them to really focus on the front end, work on accessibility, work on really robust CSS and JavaScript. And I do want to mention that if you're going through a migration like this one of the biggest things we had to do was kind of get out of our own way and reevaluate our content model. It was important that we did that exercise and not try to shove this into our Drupal 7 current content. It did mean we had to do a migration but in the end it allowed us to create a really robust model for how sites are constructed going forward. We ended up reducing our content types in Drupal 7 from 28 to 12. So we reduced it significantly. And also decoupling that content from display really allows that content to be reusable. There's some tricks you have to be aware of for SEO. You don't want to be plugging paragraph content across your website and maybe get dinged double for SEO but putting rules around that and process around that just allows the site, sections of the site to stand up really quickly and look really nice. I'm going to pass back to Carly. She's going to talk a little bit more about some of the results and the learning from the overall project. So design.northwell.io is our publicly accessible style, guide and pattern library. So feel free to visit it and take a look. This is what we share across all of our different design teams or vendors and agencies that work on all different Northwell digital properties. This site acts as our single source of truth for Northwell's digital design. And it really helps us to make sure that everything stays in sync across the multiple different properties. When we give this to our design partners we know that they're using the code that we've built so we can guarantee it meets our standards for usability and accessibility. And one of the greatest benefits to having a design system in place is its ability to be teachable. It's really hard to teach something that's ever changing. So once we had our library of reusable components we held classes throughout the marketing department to teach people why they are designed the way they are and how they can be used to assemble pages. We explained it to everyone as a Lego Lake design system where we printed and actually laminated each component so that they could touch and feel them and move them around to create pages. Similar like they'd be able to do in the back end of the site, the site builders with the different paragraphs, they can move them around. So once people were able to actually touch and feel it it became very real to them and much more understandable. We went from having only three digital designers to a team of more than 50 people who felt empowered to work with the clients, our doctors, our physicians to pull together different web experiences. With these trainings everyone felt very confident that they could articulate the design decisions that went into creating the design standards. So having such a flexible design system coupled with the way it was built in Drupal 8 lets our site builders stand up websites very quickly with minimal design oversight. Having a team of three people and a very large organization made a very difficult time-wise to actually do other work when we needed to be involved. Every single time a page needed to be set up. So now we have a lot of people who feel very confident doing it. Here's a few examples of Northwell websites that have been created since we set up the design standards. The one to the left is what Northwell.edu is going to be as soon as we migrate that page over. The other two are already live. There's the Coinch Children's Hospital website and our Orthopedic Institute. And you can see these compared to the earlier slide. These definitely now truly represent our brand and they're all speaking from the same language. And that's it. So we're happy to answer any questions or have any conversations with anybody. Please come to the mic if you guys have questions. Thank you. Hi, thank you. Any, do you work exclusively with Pattern Lab inside Drupal or have you worked with it with other backend platforms such as WordPress or Joomla or anything like that? And is there an easy, seamless integration between those? So currently we only work with it with Drupal. I have looked into using it with other backends. We use a PHP framework, the Yee framework which is NBC framework. It is compatible with Twig so I did investigate looking there. There's some work that has to be done. I do know that folks do use it with WordPress. There's, I believe a plugin for WordPress that will support Twig and people have built stuff for like a WordPress theme and they can actually contain their theme like their branding I guess in Pattern Lab and then export your Drupal theme or your WordPress theme. I do know that phase two is working. They're gonna have a version 10, I think they're calling it Particle, which actually is gonna even deep couple it further so you can completely maintain your front end code in Pattern Lab and then through a build process spit out your theme files for your various applications. So while I think the tools are probably not in place right now, it's a lot of ad hoc stuff, it's coming. So expect to see it, thank you. I have questions about your marketing users. The people who are actually sitting there with their laminating cards and figuring out the pages. If you can describe a little bit about just who they are in your organization or like their level of experience, their comfortableness with digital because we've attempted to implement something like this and we've run into roadblocks with getting people time and getting them to focus. Yeah, absolutely. So the folks that we've empowered to use the components are our marketing directors. So they work directly with the service lines and hospitals to understand what the needs are for the different clients in their website. So they're really good at, I think, like really getting down to the core of what the priorities of the different pages need to be. So then they actually come back to us or come back to the site builders with sort of like what is their proposed structure and how they think it should kind of go together. And we'll give them recommendations if this component actually would be much more effective, it's a little bit more prominent on a page. Why don't you try marketing with that? But generally they work directly with the stakeholders to understand what their needs are. So they're very connected. Is this their daily life, is most of their life this? Or just a small part? So the marketing directors oversee the digital as well as any kind of like print or anything else that they need to do with the service lines, but that is their job. And they're dedicated to different service lines. We have people specific for Pied, specific for Ortho, a couple do multiple, but that's the day they breathe. Okay, cool, thank you. Hi, how'd you get the twig tab on your pattern lab? It's a great question. I believe it's part of the starter kit that we used. So we use the pattern lab twig starter kit, which I believe has that built in. I'm not 100% sure, but I think so. Yeah, we use that as well, but maybe it's an older version. Perhaps there's been an upgrade or something. It's just something that allows poking through your site that you guys have. I'm not 100% sure, but I can ask around. Cool, thanks. Thank you. Do you ever find yourself fighting against this kind of blocked in design? Sometimes in my organization, the higher ups want a big change. We need this one thing to stand out compared to all the other sites. And so how do you fit that in to bring attention to this one event or something like that? They listen to us, it doesn't happen. Okay, get it. I make them listen. No, I think that showing everybody all the work that went into building the system that we built, why are our links blue? We had usability concerns. We had accessibility issues. And so really making sure that people understood all the work that went into it and the why behind it has really helped empower our marketing directors who are working with the clients to say, no, we can't make that green and here's why. So it's really just an education process and then having everybody sort of be your army out there about constantly championing why we need design standards, why it's important and the value that it's adding to the business. So it's really just education. Thank you. I would also add too that there's, there is a, at the end of the day, it's time and money too. So there's some advantages of, in their minds making compromises to use the components that are built and tested and ready. As long as it meets their needs, sometimes it's usually, when you get down to it, it's personal preference that they really want it one way versus another. And I think proving that these are tested. We built the accessibility into these. They work really well with all the other components and it helps sell the store, like sell it. Yeah. And one more thing is just, going forward since we're not scrambling to create things over and over now, we could actually do testing on the websites, making sure that we are getting the, the cost of action that we need that we're driving enough traffic. So then we could focus on actually knowing whether or not we have a problem before we just try and fix things for someone because somebody likes green. Hi. I have two questions actually. One is related to the design, where you had said that your content types don't really have any design preview. Do you feel, have you gotten any feedback from your content editors about that they love that, that they don't have to worry about design, or are they frustrated by that experience? A little bit of both. I mean, I think they like it now that they're familiar with using it. At the beginning, it was really hard to get people to understand like what was the content pattern with no visual description to it. One of the things we're looking at is how to make like the back end actually show people how their content would render if they were to put it into a hero component or put it into a teaser component. They, I think that they like it a lot now because previously, if they wanted a promo and here it's purple and here it's blue and they had to create it three different times and that just got like completely unwieldy in the back end. There were so many different promos, like thousands of them. You didn't know which one was which. But what they like about it now is that they can only have to change it one time. So it's definitely better from like a maintenance perspective. That was actually part of my second question is I wanted to know if you could talk more about the technical aspect behind the scene where you can actually reference something else and then have the option to override it or parts of it, like how are you storing that data? Right. So the paragraph itself contains the display logic. So if we're talking about a hero component and we have five variants for a hero, the paragraph is intelligent to kind of know, like we provide bells and whistles and switches that let the site builder to decide what they're displaying. So if the hero itself can have the image on the left or the right or it can have a purple background or a blue background, the site builder has that control. They can then apply what we call the content pattern to it. The pattern contains the data. So the title, the image that's being used, all that kind of stuff is a separate setting that the user or the site builder applies to the component. And then we have, because sometimes we over engineer things a little bit, but also sometimes it saves us in the end, we have the ability for them to override any of those fields. So the pattern, I'm sorry. I'm sorry, including the content. Including the content. So the pattern itself is the important part. The pattern is the fields. We have a data container that stores those fields separately so people can reuse that block. But let's say they pull in this block that advertises our emergency room at our pediatric hospital. So it has the title, it has a nice graphic, it has description text, a call to action that will take you to that page. But in the context of the page of the site builder's building, let's say that call to action doesn't make sense or that image doesn't work with that page, they have the ability to just override the image. And they do that on the instance of the paragraph. So only on that page is that field overwritten. So for that page, for that field specifically, they have the override capability. Which actually makes it really, really flexible because now they have, all the other fields are being pulled in from this common object. And if it's updated in that common object, it flows down, but that image won't change because they specifically set it on that page. Is that idea of like paragraph instances unique to your site? Like do you guys write a lot of custom code to achieve that? No, we handle that on the theming side. So basically we just do a couple of checks that say if within the paragraph, so part of the pre-processing stuff I talked about, we determine if there's overrides available and if they are, we pass those down through the theming layer instead of the data coming from the entity reference of the content pattern. Okay, so there's still a source of truth of the original content. And at any time you could go backwards and say I still want the source of truth, but you can also override it on a per instance. On a per page, per paragraph instance. You can actually drop in, let's say multiple promos on the same page, referencing the same entity, but override fields on each instance of that promo if you wanted to. Thank you very much. And not any other questions. Thank you very much. It was awesome to speak here. Oh sure, so the question here was how do we manage responsive images? So we actually have a digital asset management platform. We use Binder and we pull those in and then we use Drupal's image to translate them to like the smallest size possible that we want for the space. We don't actually have like a dynamic solution for mobile versus that. We're looking for solutions for that, but we kind of try to work with the largest possible that won't break like a mobile or a desktop experience. Yes. I just had a question. Sure. So with your content types, you never analyze them? No, we don't. It's all handled through the paragraphs. And the paragraphs you can move them around within the backend interface. So you can decide the order. But the way it works is we don't have like a traditional right sidebar or left sidebar. So it's really just vertical slices that, or sorry.