 This is our session, Theme Driven Development launches travel port onto Drupal, so we've got a panel discussion today with the media current team. We're going to talk about the business benefits, the way we implemented Theme Driven Development, the project management process, and how that resulted in a successful project with the travel port today. So I'm Shelly Hutchins. I'm our director of marketing. I'm going to lead our panel here today, and then we're going to leave plenty of time for questions at the end. We've also got Jeff Deeks, our SVP of professional services, Alan Paquette, our senior project manager, Matt Smith, representing our front-end team, and Derek Grace representing our developer team. So again, we're media current. We build highly impactful, elegantly designed Drupal websites that accomplish the strategic results that teams need. What does that mean? We want to make sure that we understand your business goals, your strategy goals from the beginning, and really carry that through the project from beginning to end. So this is an example of how we did that with travel port and how Theme Driven Development benefited all the parties in the process and really were able to help them meet those business goals that they had. So first question is, who's travel port? Does everybody know who travel port is? So they're the world's only true travel commerce platform. So again, do you know who travel port is? Okay, so that's exactly what we're trying to solve for with this case study. We wanted to make sure that when we all worked together with travel port, we were able to take those personas and those stakeholders and really help define what it is they do across the board. An international company, a lot of different stakeholders, a lot of different content people, and really help streamline that. And we use this process with Theme Driven Development to really accomplish those goals. And we're going to take you kind of beginning to end a cross-section of our team and how we were able to accomplish that. So with that, we're going to talk about the site and about the project. Thank you, Shelly. You're frustrating again. Yeah, that was a great transition. So you see the GIF here. This is the travel port website prior to our update to it. So you can see it was a non-responsive website, so that was one of the things that we did want to tackle with it. And a few of the specific goals that travel port had when they came to us was to make a marketing website that was focused on an updated branding and design. So they had worked with a third-party design agency to have an updating design that they wanted to have this new story to communicate on the web and have this marketing presence. So that was their primary goal. The second goal was eliminate the cost associated with the proprietary content management system. It's kind of preaching to the choir with you all, but Drupal obviously has no proprietary costs associated with it being an open-source platform. But they were on a platform that cost them money for both the users and just the operating costs for it and all that sort of thing. So they wanted to get away from that model to where they weren't being charged just to use a system. Third goal that they had was to develop a website that would scale well with them as they expanded into new regions and additional content. So they are an international company and they wanted to make sure that they had a system that was going to be able to expand with them as they grew their audience and we are actually in the process of helping them work on localized sites and incorporating translations as well. So we've continued that work on to help them get to that goal. So timeline for the project, it was six months to complete the entire site overhaul from start to finish and we launched successfully back in September of 2015. So we still are on a retainer contract with Travelport supporting them with maintenance and new features and updates and continuing to improve the website and as mentioned we're working on translations and localization currently. For project management we had a scrum approach for it and many of you are probably familiar with scrum but that gave us an iterative approach to development so we could have constant feedback cycles between us and Travelport to make sure that there was constant communication on building what they wanted. So we did that with usually two to four week sprints and so we varied a little bit just trying to settle into the right rhythm for that. What we found is three week sprints for this client is about right for the pacing based on the approvals and time to go through to get the work approved during the sprint. For releases we were doing a release per day to a staging environment during the production phase. So what we were doing, you'll learn more about this from Matt and Derek is that we would have new content that would get pushed up to the staging environment as often as possible and we'd do that once a day and then periodically we would have sections of work that would be ready to go to a pre-production environment to help us get prepared for the launch that took place in September. After the launch we do one release per sprint so just based on how long that sprint is and as mentioned before the three weeks seems to be about the ideal. A little bit beyond that it's kind of hard to get all that work bundled together shorter than that and the approvals get tough for working through the two different groups. So moving on to Jeff next he's going to give us a business overview. So within that, hi everybody, so within that process that Alan was outlining, you know, it was an interesting team that we assembled, you know, thinking about this, putting it together, had people all over the world. The travel port team has a marketing and content team based in the U.K., have others focus on user experience and site administration, content production in their Atlanta office, also work with some contractors and other members of the team all the way to the West Coast. Also working with travel ports brand agency based in London producing some of the brand styles and then of course Media Current as Shelley gave you the overview as a distributed team stretching kind of coast to coast in the U.S. So this was interesting and kind of illustrates one of the things we run into on enterprise projects a lot. These teams even within travel port had people that hadn't worked together before. In some cases they were meeting one another because they have their normal roles at travel port but when they're working on a project to build a website for themselves, you know, it's a new team that's assembled and new people kind of working together. So as we're coming into the project and we see this not only on this project but others, we're introducing folks to one another and kind of helping bridge that gap of did you speak with this person over there and have you thought about talking with this? So that was interesting and one of the things that helped get that underway and is how we like to start engagements like this is with the discovery phase. So the discovery phase isn't just to define the site but it's to help understand the team that's going to start to work together and how everybody's going to work together. So we're defining both the process and introducing everybody to one another and also defining the work that's going to be done before it gets underway. And so, you know, as part of that phase some of the things we identified early on was a need for flexibility on landing pages and to really come up with a component based system so they could mix and match parts of pages. The other aspect of the project, you know, Travelport had gone through a rebranding with their agency in London and had this new brand and messaging to share as part of this website so it wasn't just about making it responsive with the same content it was producing new content to help tell their story better. And we have here, you know, story driven content structure and what that means is really for the potential and current customers of site, they all have a story or, you know, questions they're trying to get asked or needs that they have that they're visiting the website for and each person, you know, has their own story, you know, what they're interested in, what they're looking for and we wanted the site to help guide people to the right place using those stories rather than just plain old navigation menus and assuming they'll find their way. Again, using those components to mix and match and assemble in the pages to help them kind of identify and find the pathway through the site. We also learned about, you know, differentiators between Travelport and its competitors and how to emphasize those and highlight those in the site and the content that was being produced. At the same time that, you know, all the team was meeting one another, defining this process and we're defining the website, you know, Travelport itself is moving towards, you know, some more agile processes and new tools to facilitate those at the same time. And this is, you know, I think the first instance of, you know, the company moving away from internal IT department hosting for their website and some of their applications and trying to move some things into the cloud, sorry to use the phrase the cloud, but that's what they were going for. Specifically, the site is hosted on Microsoft Azure. It is still running Linux virtual machines on it, but we were able to work with that and learn a lot about that along the way to get it working there. So one of the specific, I guess, differences or things we want to highlight here is the approach in the theming. So I'll call, I guess if I can call it a standard Drupal development process here on the left, the workflow maybe looks familiar, design development theming QA, UAT, right? So we're gonna design our page or piece of the page, you know, through mockups, things like that. Then we're gonna go through and set Drupal to handle the back end of how this content's gonna be produced or output that. And then hopefully a themer comes in and makes, you know, that Drupal generated markup match what the design suggests and try to match that mockup. And the problem that you can run into in this process is what if the outcome of that theming doesn't match the expectations or the result. Somebody who's a reviewer or a stakeholder in the project sees what it's actually going to look like and realizes that's not gonna work, we gotta change that. That goes two steps backwards. So there's already been development done. That's gonna have to be reworked potentially to match whatever that change needs to be. So theme-driven development flips that part of it a little bit. So what happens is, you know, through discovery and design, now we're working against a mockup. First step is to produce the theme element for that component using some technology that Matt's gonna outline before any backend code is written. But those components can then be combined to produce examples of entire pages of how those would come together. They can be fully browser tested, device tested and reviewed for what the output is going to look like in the end. The theme's already written. And it suggests the markup that needs to happen for that theme to work. And backend developer comes in, has their target markup to hit and sets Drupal to hit that target. So what happens is, instead of developer being off in mystery land, you know, making the Drupals happen, right? The travel port team's able to see and experience and interact with what they're gonna get. And that catches things that might need to be tweaked before code has to be written. So we think those components really help catch things early, prevent rework and help the project move along. The other thing that helps with in the component-based architecture is it's a measurable thing, your progress towards the end of the project. So typically halfway through the project, you've ever been hit with the question, well, how far or what percent complete are we? Maybe somebody will be brave enough to try to put a percentage to that. But what's that really based on? Working with components, if you're outputting 54 of them and 27 are complete, you're probably about 50% complete. It's an actual number based on something because the component is done, right? We, it's been approved and reviewed and tested and verified that Drupal can hit the markup and output for it. So these components were kind of a key piece of this, working with the theme-driven development. So speaking of these components, just one other thing to think about, not necessarily specific to this project or travel port in general, but in enterprise projects where we're working this way, those components are tools to be used in a content management system. No different than a farmer has a tractor, that's a tool, that's an asset that he has. And industrial machines are tools. Your CMS is a tool used to produce something for your business. And that way, it can be considered an asset that can then be depreciated. Which leads to, if you're working to justify budget for a project such as an enterprise redesign, this is something to be covered with the finance and accounting team that can kind of help justify that and account for this asset that can be depreciated over time. And maybe make some more budget available to really build a world-class site. I do need to say consult your own accountant and finance team. They may give you some fine print, such as what we have here. Not everything can be capitalized for work on a project, travel and maintenance and support costs and other things that aren't directly tied to producing that tool that's gonna be used and placed into service. But to speak more of these components and how they came about and how to generate them, I'm gonna throw things over to Matt and then Derek to walk you through a little detail. So we wanted to give a little project management business overview, but as a case study, we did wanna get into some of the technology behind it as well in case anybody's curious from a theming and development front. Go for it. Right, so whenever we were going through theme-driven development on Travelport, we did it specifically with KSS Node, which is a Node.js implementation of a style guide tool called KSS, which stands for Nile Style Sheets. The KSS Node library, essentially you would take a standard set of comments that are added to your CSS files and the theme that already exists and then it can read those, understand those and then build a very human-friendly style guide that can be reviewed and used later on. It's compatible with pretty much anything as far as creating the visuals goes, so straight CSS is fine, any preprocessor, so less SCSS, so on. So it kind of goes with your build processes that are already in place. Markup can also be as simple or complicated as it's needed. So these components are flat versions of the components that will be used on the live site later on. So they can be flat HTML or they can be more complicated and use handlebars with logic and variables and a little bit more involved there. And as far as what you get out of that, the style guide serves kind of three main purposes. It can be used for documentation, which is a little bit more optional. You don't have to document particular parts, but there is good payoffs there. There's a visual preview of each component so that you can see what it's gonna look like on the live site. And then there's also output code that can be used to see what code makes up those components. And that output code can, there's a couple good use cases. One of those is that can be handed off to backend developers. Another is if you have third-party vendors that need to integrate, it gives them a markup and CSS target that they can shoot for. And another huge benefit for CSS Node in particular is the template language it uses. Handlebars can be used to generate full mockup pages of the site. So, and this was something that we did on Travelport specifically, is we took our components, which can be nested inside each other. So if you had like a link component, you could also put that inside another component, such as a form or a sidebar block. We kind of went much further with that so that we nested components in each other to build entire pages so that we essentially had a flat version of the site, completely separate from Drupal. And that was much earlier on in the project. And this is an example of the style guide page that's generated by CSS Node. So we have the, it can be customized to their particular brand as needed. And we've got our logo in the top left and it's following their topography conventions. The left sidebar is the kind of a list of components. It's, so it generates them and steps through them alphabetically, but you can also order them as you need to. And then this particular component kind of shows all three of those outputs. So we have documentation at the top, which is just a summary description that can be as simple or complicated as needed. So some of these are just one sentence to say what it does. Whereas others might have multiple paragraphs and lists where it says what this component is, what the different modifiers of it are, and so forth. And then there's a visual preview of it so that you can see that this is what it should look like. This is what your backend developer should target. And then below that is the markup that's used to generate it. And then this is an example of what the markup file might look like. And aside from a few kind of custom variables that are in here, for the most part it's just HTML. So your developers don't have to learn a new complicated templating language to do this. They can reuse the knowledge they already have in just HTML. And it keeps it very lightweight as well. So how does this kind of compare to normal theming? And sort of the summary of that is there's more planning involved and there is less rework and less fixes going on. So it takes a different approach to where it's making the components semantic versus the normal Drupal element components. So we have semantic elements where it might be footer underscore underscore text versus Drupal's filled hyphen hyphen footer hyphen text. It's more specific to the exact components. And in this particular case we used BIM naming conventions in the CSS so that we could keep our nesting and our styles pretty limited but also have components relate to each other. One very important part here is establishing a functional spec early on so that you know where your markup is and how it relates to Drupal core. And then another thing to kind of consider is how Drupal handles its element. So Drupal rendering is element based and it's very easy to kind of go overboard with the BIM naming conventions that I just mentioned where you might have classes that are specific to the individual page or a little bit too deep into the component. So nothing to always kind of remember is to stress reusability so that you don't go too far and make the components too specific. And then another big benefit here too is that accessibility is always important in pretty much every website and the earlier that you can tackle that the better. Because you have a real markup target and it's real market that will be on the side eventually you can check those accessibility issues much earlier in the project. So in the first few months you can go in and work out those accessibility problems. And you can also review it from a backend perspective and say that maybe no this component doesn't work well with what we need we might need to rework this particular part. And then another thing to kind of consider as well is even though that KSS node is kind of the it's the ideal situation because you're making HTML just from scratch so you can keep it extremely clean. You always have to be kind of aware of what Drupal does. So if there are any particular limitations with panels or the way that panes work or template structure, even though that KSS is the ideal case your front end developers need to be aware of that. And then this is an example of how a component might be different in the normal Drupal theme fashion versus BIM syntax where we've got on KSS node. So on the normal one we have filled quote text and for the most part it's like block hyphen hyphen quote or filled hyphen hyphen quote text. So it's very generic pieces that can be reused throughout the site. But they don't necessarily have the clear meaning that might be needed in the theme versus on the semantic components it's related to. We have quote and then we have quote text and quote author so that it's more specific to that individual component and it prevents kind of stepping over your own feet on the theme. And then kind of some gotchas to watch out for and in particular our elements. So as I said before we use KSS node not just for the style guide but to make full page mockups of the site for review early and often. With that there are some particular pains involved in creating those mockups to watch out for. So the prototype page template should include reusable components where it makes sense. A good example of that would be for the head section of a page because you might three months on the project add new viewport tags. And if you had to edit each of those prototype templates for something that should have been reusable it's something to watch out for. And another thing to consider too is especially in Drupal 7 whenever you have image tags to consider that ahead of time and sort of format those the way that responsive modules would expect them such as the picture module and image source set. And then another thing that is very common to run into with KSS node is having an issue where you've got links in places where you don't necessarily need them. So since you're using such a clean target it's easy to write a link around for instance an entire component whereas in Drupal you might have a contextual link wrapper that interferes with that. So you need to watch out and make sure that links are on the specific portions. Another thing is as I mentioned before accessibility can be reviewed early and often and that's another point because the markup is being generated so early you can review that early and often by accessibility back in developers, the client. So it's always extremely important with this approach to have that reviewed early. And one thing to kind of consider with KSS node is it's using in this case handlebars but handlebars is a very simple templating language. It's for the most part HTML but with a few additional logic and variable bits on there. So if you need to do something more complicated such as a for loop or anything kind of outside of that basic level to write a handlebars helper that can be used to kind of get around that. And handlebars helpers are just JavaScript files that interact so you pretty much have the full power of JavaScript that's available to you there. Another thing that we ran into as well is to watch out for how your assets directory in the theme is organized. Because the style guide is integrated directly into the theme the images are also coming from it. So it's easy to get content images from your style guide mockups mixed in with your CSS images such as the logo or icons. And establishing a good structure to keep everything organized early on is also important. And a performance consideration is that KSS node is very specifically built for building an overview page like from before. It's not built for building multiple mockup pages such as if you had a services page or solutions page and entire flat versions of the site. For something like that you may want to reuse like the handlebar syntax with a lighter handlebars compiler versus using KSS node itself. And then with that I'm gonna go ahead and turn it over to Derek to talk about the backend perspective. All right, thanks Matt. All right, normal development. Teamwork is key as always but especially with team driven development it's really important to have both your front end and your backend tightly integrated and have a lot of communication between them. I'll touch on that a little more in a second. Once again, so important we said it twice a functional spec, it's not really optional. When you're building out your components on the front end you need to already know how that's gonna be reflected in the backend. So that's not something where you can kind of go in and develop it out and say okay this affects our front end in a certain way. You need to have that communication going upfront. So again with that requiring the more communication integration with the front end developers and backend developers. Something you can really do that'll help a lot is providing non-negotiable markup to front end developers at the start of the project. So things like fieldable panels, panes, paragraphs, panels, many panels, output from views it's not really conducive to reworking completely. If it's something that you're gonna have or you know you're gonna have in the site for your functional spec that's something to provide upfront. Theme driven development can be much faster especially if the developers can make changes on both sides. So if you're a backend developer and you're looking at something and thinking through how it's gonna be built out and you go hey what if we made this small little change to the markup it would make things generate so much cleaner and be a lot better way to do it. If you can go ahead and make that change and then communicate that to the front end team instead of having to wait for them things will really speed up. And same thing if you're a front end developer and you're looking at a component and you're like oh what if we change the markup this small amount then the CSS and theming can come through a lot cleaner. If you can go into the backend and make that one little tweak without having to wait on the backend developers to get back to you and make that communication work between the two teams really helps speed things up. So some of the questions that get answered way better with theme driven development versus a standard development process is stuff such as how close is this to client ready? Well with theme driven development you have your style guide already you can say well we have the markup we even have the JavaScript components if those are necessary those are all ready to go those are shipable and we know exactly how much effort it'll take to build the backend for this gives you a much clearer picture than building the backend and going okay how do we connect this how long it'll take to add the front end components on. Another question that it answers a lot better is what did we forget? If you build out all of your front end in your style guide first and then you connect the backend to it and certain things just aren't connecting you can see right then and there oh well you know we forgot this section or this component this needs to go through QA process and get verified a little better. A good example of this sort of workflow is something we like to call component issue workflow this means we have parallel issues going on all at the same time this is development and theming so our first ticket that we like to build out is a component ticket that's all the SAS HTML style guide work necessary so that's all the front end stuff that goes straight out and is visible to the client ready for approvals at the same time we'll also have that build ticket going and that's all the backend work so that's informed by the design and by the front end components and we'll also have the theme work going on if necessary all of the twig or PHP templates that need to be done all the preprocess all of that can kind of come in all at the same time pretty much and so these tickets sort of arrive usually within the same sprint and then we'll have a finalized ticket on top of that and that's built out to allow review, approval and lock ins of the actual components themselves from delivered really good quote here by Phil Carlton of Xerox and Netscape fame and the part we really want to focus on is how hard it is to name things so with front end driven development that's where that communication comes in so I'll kind of go a little more in depth than that in a second but I kinda wanna do a throwback as a lot of you are probably thinking well we've tried something like this before we had a markup target especially like in the Drupal 6 era and we had all of our developers working around the clock to get all of our markup from the theme layer to output exactly like what we wanted and it was kind of a pain it was way too much work for very little gain so that's the elephant in the room and one of the things that was really missing from that time period is key components such as KSS and base theme awareness and those are the two things that really changed it up for us and allowed us to take another look at this process so with KSS there's better compromise as far as between front end developers and back end developers on the markup targets front end developers have better communication with their being made aware of pain points for generating markup straight from Drupal and vice versa the back end developers are more aware of the good markup targets from the front end that they can kinda bake in to how they're building the site in the first place so back to naming it's very easy to get lost in who names what and if things conflict how do you resolve them so you kinda found the best way to do this is you have the developer and the designer coordinating and generating a content model from your functional spec so when you have a functional spec listing out how everything works you're gonna take that and generate a content model from it that uses all the same naming conventions all the same ideas and things like the label machine name cardinality type all that stuff you should be things that you're discussing and documenting before you're even building them out on the back end so this way you can coordinate your effort to reduce the waste and rework that's involved as much as possible another good pain point to keep an eye out for is views, a lot of you are familiar with some of the horrible markup that comes out of Drupal 6 and 7 views and a little bit in Drupal 8 though it's definitely better you wanna plan for it up front absolutely so you wanna standardize how you're configuring your views output know if you're customizing it either in the views themselves in the GUI or if you're gonna use pre-processing templates or even a combination you make sure that standardize up front because both choices do have issues so what we found to found though is unless you need your website editors to actually be changing the markup and the classes that are applied it's generally better to have an organized plan of attack and use pre-processed functions and templates on the back end it's also very important to note that views in Drupal 7 will always convert underscores to dashes in the output so if you're planning on using class names that are consistent with your style guide then you need to understand that views can't always output those dashes versus underscores so the template.php one of the things that can happen is it gets really, really massive and this isn't something that's unique to theme-driven development it's something that we've seen across all types of development with Drupal sites something that helps a lot with that is learning to organize and split up all of your different hooks all of your theme functions that you're adding in and you can do that with PHP require once is or module loads where necessary and this makes it a lot easier to locate specific functionality as well as having multiple developers working on the theme at the same time you'll have less merge conflicts because all of that functionality be isolated to their own specific files that are then included into the template.php finally, theme-driven development does not mean that you avoid building your content structure until the front end work starts instead you should start building it as soon as the functional spec and the content model that I referred to earlier is defined so that includes things like content types, fields, paragraphs, feelable panels, panes this will allow you to give your front end developers a clear picture of what the base markup and organization can be like and it'll help inform their choices on component organization so once again that's that simultaneous front end and back end and design all working together and happening at the same time with enhanced communication so what we learned and future outlook there's a lot of love there's a lot of love with theme-driven development everybody seems to love it all our developers, project managers especially clients the fact that we can go and build out a component and say hey, here's the working CSS here's the working HTML here's the JavaScript you know is this the vision that you're looking for you know it matches the design we think the functionality is really really slick seeing these animations and the motion in action it's really great and here's how we're planning on tackling that back end gives clients a lot more confidence in that kind of conversational process as you're building the site we've also internally found that using a semantic component convention for markup is a lot easier so that was the one where the component names weren't based around the Drupal components such as blocks and fields and that sort of thing but instead they're based around what their designers are coming up with and so when you do that coordinated communication between your developers and your front end guys and your designers that sort of stuff all of a sudden becomes way easier to talk about you no longer have to worry about oh well I thought this was supposed to be a block or a paragraph or no it's it's a component and it's a really good way to communicate not just amongst yourselves but with clients another thing is some clients or I'll get to that in a second sorry Drupal 8 and twig so D8 awesome it's more flexible than Drupal 7 and one of the things that we've been investigating internally is building completely semantic components driven themes for Drupal 8 so instead of having to do a lot of that markup in the theme layer and do some of that translation ahead of time to semantic components the theme itself will handle it and we won't have to do as much custom twig or PHP templates so and then finally client approvals and lock ins some clients view an approval of a component as a lock in for the markup or exact functionality that you're discussing so for this reason we recommend having ongoing approvals for components during your sprints but only allowing these components or sections of the site to be locked in once the entire section has been completed so if you're building a small component such as a search bar or something like that you can get approval for the markup you know for the design for everything else but you don't want to lock that in you don't want to say this components completely done until you've integrated it into the rest of your search functionality on the site like maybe the results page or that sort of thing so that way you can make your tweaks necessary as you're going on with the agile development in order to get the client feedback that you need and then lock it in once that entire section is done and it's good to go that way you don't have to worry about coming back to the client like hey I know this was done already but we want to make some of these changes that way it's just everybody's kind of locked up on the same page so moving on to the project management side so within the project we have several project management tools and processes that we use to help facilitate this theme driven development so our specific ticket workflow is listed here for you so we have a backlog which is the to do status so basically what it says it means that it's something we got to do from there we move it to in progress and then it goes to internal review once the developer has gotten it to a state that they want to have peer review on it from there we move it to a for approval status which is for the client to look into that and make sure that they give it the thumbs up and approval for it that work typically happens on staging so as mentioned before we're gonna make a deployment to that staging environment for the client to have that approval take place once they give us that approval we move it to approved and then that lets the developers know that that one's been approved to go into production and what this helps facilitate for us is that coinciding development work to take place just like Derek and Matt were talking about it's not a sequential thing it's coinciding so they could be working on both the front end and the back end for component at the same time have those in progress at the same time and move them through together rather than having to wait for development to go all the way through that cycle and then front end to come back behind it as well. As mentioned before too this also allows us to use client walkthroughs so during that approval phase we can take the KSS style guide that has all of the component built out in a browser for them to see how it interacts with browser resizing clicking on it all that sort of thing full functionality is there for the client to see before the development has actually begun with it from the back end side of things. For documentation we also make sure that we've got a wiki to go along with all this to show technical documentation and this helps for multiple aspects both for the internal team we can ramp up new team members much faster because they can see documentation that we have in place on the project and the components that have been built out there's also process documentation all of our meeting notes that there's ever a question about a component and what it should contain from functionality or theming wise and then also release notes so we can keep track of what components have gone out and what feature set was included in each of those releases. Also to go along with the agile project management we're doing sprint planning and retrospectives and summaries in that documentation too. So we've come to the end of this theme driven development what does it matter to the business and what it all boils down to is these things. So we found within it that there is these analytics coming back through to show a strong increase in visitors and user engagement. So it's metrics that are displaying and demonstrating that we have actually accomplished what travel port set out to do. Shelly are we missing a few slides here? There it is. This is the one I was expecting. So this is the bottom line with theme driven development and there was this subtle theme going through everything that we talked about here today. You can spend less time and money and get better results and there's that classic triangle where you have quality time and money. What this process does for you is it allows you to spend less time and money on it so you don't have to invest as much of your budget into it. Clients don't have to worry about what you're doing behind the scenes of things. You're delivering things on a regular basis. If you're working internal to an agency or inside an organization rather than an agency work you are showing your stakeholders that there is value coming from this team. And what happens with that is you get a better end result because everybody has been able to be collaborative through that process. So it's gonna be much faster for you much more efficient. There's less rework happening and going back and forth between it and that collaboration takes place both within the development team but also the external stakeholder team because they are involved in that process from a much earlier on point. So if you look at the standard model as Jeff was talking about earlier it could take two weeks before you actually show anything to the stakeholders. With theme-driven development it could be a matter of a day or two that you're putting something in front of them to get their buy in on it. Once you have their approval on it that enables you and the rest of the team to go and build that out and have assurance that it's gonna meet the needs of what they're expecting for you to be building out on it. So with that I'm gonna pass it over to Shelly. She gets to tell you the fun stats. Right, so as Alan said and the rest of the team we took you through the entire process. We talked about how our project managers manage this process. We talked about how our front end and backend teams work together. We talked about the business overview but at the end of the day all of this was to accomplish the goal for the clients that we set out in the beginning which was to help people understand who they are and to visit their website, spend more time there and really engage with them in a meaningful way because before the branding was changing and it was really hard to understand what it is Troubled Port does for the stakeholders that they were targeting. So we worked together to go through this process. Our average session duration increased 85%. Pages visited and went up, balance rates decreased more by half and you can see that the client was happy with the end results is that almost immediately with their rebrand with the new website and going through this process speedy as Alan mentioned, saving time, saving money, being very efficient, we were able to produce those results. So that's the bottom line is that we really wanted to take you beginning to end how this theme driven development process works to benefit that client to take care of those business and strategy goals that we laid out at the beginning of the project and kept that in mind all the way through with every component that we were putting on their site. So with that, I'm going to open it up to questions. We do have a mic right here that we can put out in the middle there if anybody has any questions for any members of our team. Any questions? Okay. Well, our team will be up here if you want to talk any more about the project. Oh, good question. Yeah, I was really happy to see that you're using KSS node. I'm the maintainer of KSS node. And I just released a version that uses twig just like a couple of weeks ago. So I wonder what your thoughts are, what your plans are for going to DA to the twig and the fact that KSS node then also allows you to do that. Yeah, you want to come answer? Yeah. Okay. I'll let you hop up to the mic and answer. The update to include twig on there was actually one of the things where whenever we were first working on travel port, we were kind of keeping up with that with what templating languages were available to use on it. And we saw that twig was in the roadmap and the whole time we're just like, this is so exciting, but it wasn't at the time. But it's something, something at going forward on projects and possibly since this is still under active development through the retainer agreements that it's something keeping a very close eye on. And another thing that I would like to get us to is to where we can basically just drop in. So if we have a twig template that's built in the style guide portion to take that and just more or less use it in place in the Drupalate version. And that would kind of be the ideal so that there's not that rework step of building the market target and then going back in and then building the Drupal version as well. So any other questions? Thank you much. I'm supposed to plug Sprints on Friday. So join the code Sprints. And also you all join us this evening with Lingotech having an after party over at the Rusty Nail with a crawfish boil. So please join us. Come find one of us if you need directions or anything. It's nearby.