 but very happy to be in Canada for the upcoming sport that I really don't care that much about. But we're here to talk about other things, we're here to talk about what we do and some of why we do it. I really do care a lot about our clients and our work and what we're bringing the power of our agency to help resolve. We believe a lot in sharing our knowledge in events like this who travel around to help build community, which in the case of the ultimate demise, is anyone still working on any Drupal 6 websites? One? Okay. So still a couple life support items, but for the official death of Drupal 6, the end of life we threw a funeral in New Orleans, a jazz-style funeral with a second line band. Dries was there, gave talks, there were hundreds of people, it was amazing, it was beautiful. And it was a great thing. We worked on Drupal 6 a really long time. It was good to send it off. We're also really interested in engaging in conference settings, raising awareness around social causes, having frameworks for donations, either to various charities, or in this case we helped to plant about 450 trees in Northern California to repopulate some of the devastating wildfires there. This was at Triple Comm this year. But enough about us. We're here to talk about this project and this client. The Fine Arts Museums of San Francisco is the, well, they're two different institutions. One is the Legion of Honor, which is a three-quarter size replica of the Legion of Honor in Paris. It's kind of, it's cool, except they don't have the dead people buried underneath. And the De Young is like the AGO of San Francisco. They're together, they're some of the, it's like one of the largest part of institutions in the United States. And this year, next year, they will be 125 years old. And so our project was about moving beyond the frame, beyond kind of the static, oh, the static, we're making static sites, but still the art is static on the wall. But what happens if you, you're not there to see the exhibition? How do you get enticed to come? What if you can't visit? What if there's more that you want to know about the history of the exhibition? So the museum had already engaged in creating these forms of educational digital experiences. And they had an existing Drupal 8 website that was built using paragraphs. How many of you have used paragraphs before? It takes a while to create a paragraph, right? Like you've got to put all the nuts and bolts. And what they found was they wanted to make some changes. They wanted to innovate on the front end. But it's kind of that all these new design paragraphs, they wanted to flare, they wanted all these other things, and they had an existing system. It was a challenge to like figure out how to do all this stuff. And we'll get into that. What did we do ultimately? This is our client that's reporting that on the success of this project. And we'll dig in a little bit more deeply. But highlights are that we built a robust toolkit and a content workflow. And we also proposed and they adopted new technologies that ultimately they would not have considered on their own. And this is a form of true partnership when we can try to bring our heads together to solve a problem differently. And I'm pleased to share how we got there with you today. Hopefully it will be inspiring or at the very least concerning. So first, where did we start? We inherited a bunch of design deliverables. By the time we got onto the scene, and just for some background, someone pressed the button for me, right? Thank you. So we kind of came in and they had already selected a design partner to do like all this pizzazz. They're called Upper Quad. We'll see some of their deliverables in a second. And we tried to kind of get in, but the process was sort of underway. So we ended up inheriting a bunch of work and the client management on the design side was very thorough. And we weren't involved early enough to build a coherent project management practice across all agencies. So these are some of the examples of the deliverables that they produced. This is one page of a style guide. I think it's about 60 or 70 pages. It's like a PDF. And they have some examples of applications of how some of these components might work. This is a quote. And some design rules around it, they explain in bullet points how they should behave. They also delivered to us eventually, after some prodding, the sketch files that they used to generate all of the different components. And then have the fonts when I opened this, so it looks a little weird if you are zooming. And they also produced an online style guide, which was interactive. That was the first thing that we saw. And it was concerning to us because they were like screenshots of things and assets and they were all just images. There was a lot of text and explanation of these things. We couldn't highlight them and they produced multiple versions of these. And there's like all these embedded videos that show all the motion. So we were trying to deconstruct this process. The tools that they used were not web-centric. Is anyone familiar with flash and like macro-media products and all these like timeline things? So they use this tool that lets them be really creative around how they're going to build transitions and move things around. And they don't connect to any real-world web libraries or paradigms of the web. So this whole design process in sign-off was in some ways informed. They did have some web experience, but not as much depth as we do. And so the rubber was not in some cases able to quite meet the road. And in that vacuum, yes, beautiful pieces of design, wonderfully self-contained issues with responsiveness. Like how can we make some of these transitions work? Here's a little video of the interactions that they had designed. It'll give you a little bit of an idea of these challenges. So here, you know, some ways that the image behind the text is coming in and moving. Here, this kind of fade across letters, like not really that typical of a web kind of thing. Like it's really hard and you have to calculate every letter and they've got gradients halfway through. Some neat stuff, this works really well, but you really need the right video in the background to make that kind of thing work. These things cool, very custom, everything very custom. Zoomy things. You can see the navigation over here on the right. A lot of really beautiful nuance. And this was a design agency that was really their forte in storytelling, in digital storytelling. And they referred to these assets and these experiences as digital stories, which as part of this process was rebranded as insights instead of digital stories. So this is a little bit of a view on what we were starting from. And very robust, they had redesigned some existing exhibitions and had also focused on one upcoming exhibition. So the content is then, you can dive deeper, they have these kind of like hot spots that you can click on to get more stuff. All this wisdom. So it was really exciting to us because we knew that the outcomes would be a huge challenge for us and we would be making a beautiful product. So again, lots of stuff, lots of documentation, some questionable portability, very ambitious design and ultimately a really tight timeline to deliver this in. And they came to us with also a really tiny budget because they were like, it's done, just make it happen, right? Wave your magic wands, wizards of the web. And they knew that we had Drupal 8 expertise and they had an existing Drupal 8 website. So how did we go about this? We were like, oh my goodness, there's like a huge design system in here. And the design agency had itemized all of these different components and given them names. And so we started to create an inventory, we looked at what was existing and what would be changing and what was new. And they had, so we identified all of their components and we found those components where the data model was close enough to be able to merge some of their components into single components with variations. And there were additional components that we needed to add. They had a plan for it that we were going to need to estimate and design. If you've used paragraphs before and you have all these different things, some of them need to be contained, right? You can't just have complex elements floating around. You have to bind them. So we have these notion of containers. In the case of this expression, they were referenced as chapters, which also would be impactful on how the navigation was going if you saw those little timelines along the side. So we took all the components and then we estimated how much it would take for us to build just the front end expression of those and then on the back end how much effort it would take us to be building those in Drupal and then a total, which was a combination of both of those. And then we worked through phasing the approach and thinking about what we might be able to launch progressively. Not all the components they had designed were targeted for the initial launch of the first digital story on the new platform or the new insights platform that they were looking to do. So we were like, well, we don't need to launch with those. Let's just focus on what we need for phase one. So we identified all the components in phase one and we asked the client as well to attribute business value to the components, which ones were most important to them so we could help to prioritize and understand the value of our effort against the benefit to the organization. And then we did a little pivot on all the different phases and figured out what all the estimates were for the different pieces. And then what we did was we said, let's not do any Drupal in phase one. Let's build a prototype and then we'll deal with the Drupal stuff afterwards. We'll back a little bit deeper into how we're able to do that. But that let us chunk things into reallocate the effort from the phase one component back at work into phase two and we got some total estimates for all the things and phase three was a series of features that we're talking about that we did implement post launch. And so this is what it looked like. We had four sprints to launch and then four sprints to build the back end. The sprints were two weeks long and throughout the summer vacations and other things were occurring. So this is another important reason why we needed to think about decoupling our efforts in order to get the product out more quickly. And along the way there were so many moving parts and things were moving so quickly and we had all the gear and the issues and everything. It was hard for the product owners on the client side to know where we were at so we made another little spreadsheet for them about where we're at, where we're blocked, what percentage along we are because everything is being worked on at the same time and everyone's just hoping it's all going to get done whereas we want to be able to more clearly identify what's going on. So this was quite helpful in extra work. So the first thing we did was we went about building a prototype. And what is a prototype and how do we do that? So we have concocted a tool called Calistatic which we've been working on for about three and a half or four years. At the time that we started developing it the pattern lab was just in 1.0 and it didn't do a lot of things that we wanted it to do which is why we rolled our own. It didn't allow us to produce any actionable prototypes. Sure you could put some things together but you can't just kind of get code at the end of it that you can really use. We wanted our prototype code to be production ready to have full control over the front end and we wanted as well to be able to share all of our templates that were in the prototype with Drupal. At the time we started developing this it was in Drupal 7 and we were interested, we knew that there was a Drupal 8 future. Maybe? I don't know if you guys were, at the beginning it was like what's going on? Is Drupal going to implode? Is this 8 thing really going to work? We started, we wanted to hedge our bets a little bit and so we focused more on the front end and so for those clients that were trepidatious about moving to Drupal 8 we could build out the front end hopefully Drupal 8 was going to catch up would be most of the way there and we wrote a small module called drupal shim which lets us use twig natively in Drupal 7 and Drupal 8 we're using twig using with some other components, the components module. But what CallaStatic does is it provides a framework for websites and web apps. It allows us to produce a style guide which is component driven and to assemble those components into a series of pages to create layouts. Those layouts produce production ready code and ultimately it helps us have some more coherent conversations between development and design where we're looking at code and talking more realistically about what's going to take place. Previously we would have a bunch of design work that would happen it would be fantastic and then the developers would pick it up and they would be in the situation that we were in on this project which is great, how do we make this happen? So by working natively in the browser we could have a lot of those conversations earlier. So in this first phase as we were producing the prototype we used markdown in order to maintain the content. We knew what all the content was going to be it had been authored, it was delivered upon us they didn't really need a CMS in order to go in and keep at it because they had their own word docs and whatever we're going to do a one time port and then some tweaks it's like they didn't need that complete independence because we were continuing to build the project. Their team was also comfortable editing markdown and then we were able to go in and do some edits and we structured things and you can start to see the structure a little bit you've got these headings and the headings create these chapters there's a YAML front matter that gets used, determines which layout is being used which template is being used for each section you can see the twig name spacing that's coming up here and some properties that are going to get passed into the templates so we built this thing and then then we put it live because it was good to go once it was live we continued to iterate and we were developing phase 2 features and talking about the CMS at the CMS and introducing new features iteratively in the static site model Any questions about that first part? How many developers were working on this day to day? Day to day So the client had one developer that was very active and we were working with and integrating into our team though we were doing the work they were getting educated along the way to get the hand off on our side we had a lead architect and two other developers project manager account manager we also had a visual designer new code and has contributed to building the calisthenic static as well it wasn't full time they had some other projects but at certain points it was the majority of the majority of the With the estimation did you do it by points or hours? Good question so we kind of did we did hours gone back and forth on that the reality is budgets are in hours and you don't really know how much a point is going to cost until the project is done so it's very difficult from a client management perspective to do estimation in points unless you have a long project life it takes three sprints to be able to report back on velocity we had four sprints and it was hard to track expectations to reality but most of our estimation is done in hours time and hours and all of our reporting aligns more fluidly with that so we really suspected along the way that we were not going to be using Drupal even though they came to us for that we started to float the idea kind of early on we knew that they were dissatisfied with the architecture we looked more deeply into it what could we recycle, what could we not recycle there were a bunch of paragraphs in there and it wasn't a terrible sight, it was pretty lightweight but it just felt wrong to be replicating the same problems they were facing by making another version they wanted to innovate on the front end and Drupal was getting in the way so why would we put another repeat experience of that Drupal has been a bit slow to innovate on the front end it's a lot better in 8 we were doing this things were still up in the air but you're relying on all kinds of third party modules to integrate libraries and do all kinds of other stuff and there's a lot of fancy stuff that you can do but we wanted a little bit more control we wanted to be able to compress, just throw whatever JavaScript we needed and for a project like this with all these different interactions we were going to really need to get a scripty and then manage it, compress it and deliver it so we thought well if we can level them up and give them a system where they're really really focused on just the front end then they may be much much better off and the weight of paragraphs is a bit imposing just creating them figuring out how to name all of them we wanted to use the right tool for the job so what we did is we made a little bit of a proof of concept in a few different platforms which we presented to the client and we estimated and built a grid of different solutions that we thought would be possible the content was in markdown so they could continue along that route or we could put a lightweight solution like pros.io which is a markdown editor that connects to your github the second version of it was built as part of the healthcare.gov and it gives you a little visual whizzy wig on your markdown you can flip back and forth and it hides the yaml front matter so you're really just focused on the content authoring but they would be giving their content authors access to the full repo and they could browse around and edit any file, not just the ones that were specified so that was very risky a very very low level of effort all the way up to the highest level of effort the extra large t-shirt size which is Drupal Prismic Netlify had a CMS Contenta CMS and we made accounts and they could go in and play around with the user experience and how they were going to own that and be able to control the storytelling and the writing and the reordering of all these components that was a really really big thing for them the way that the paragraphs were set up and we've since been able to solve this but for complex layouts where you have nested paragraphs a paragraph within a paragraph for a good while like you couldn't move it out of that space you were kind of jammed in which made it hard to orchestrate this storytelling at the end of the day the client decided they liked the user interface of gather content the most as well as the content authoring experience and we left the choice of the CMS up to the client 100% so how does this whole thing work all the code is in GitHub and we're using Netlify Netlify has a build system that's also where we're hosting the production version of the website as well as all the other environments that are created from every pull request and any edit in the GitHub repo any new code triggers a Netlify build which then deploys out to the environment gather content is integrated as well through webhooks and also triggers a Netlify build so we'll look a little bit more into gather content later but it provides these different publishing states that you can customize these are the ones that we chose for this project live approval legal sometimes legal needs to approve something most of the stuff it bypasses it and publishing so as content is moved through those different states it builds out and is deployed so they're editing the content they can see it they can see it build out so what is gather content how many people have used gather content before explored gather content curious about gather content so gather content it was devised as a means of gathering your content you're pulling it all together you want to work on it we were very interested in this because what would often happen is you build out this content management system you build all this stuff out and then the content gets jammed in afterwards and you're filling in boxes we're building a CMS C is the first word in CMS content comes first you can't validate your data models early and start to explore whether or not the rubbers meeting the roads whether you need that extra subheading field they've identified in a spreadsheet you're going to need to build in Drupal whether or not the list of options it's just really three options do you need a select here how are your data models really going to need to be built so gather content lets you build like in Drupal these sorts of forms where you can put fields and help text and you have workflow management you can add images and resource assets and it has an API that you can query in order to get that content back out it's full strength is in content governance and in managing the creation of content it can be used as well to deploy to multiple targets but it was not designed to do what we did with it nevertheless we did it so here's what like one piece of content looks like on gather content we provided these little tabs they could upload an image there's the alt text and credits for caption and then there this is for the hero which is kind of like that opening splash page thing and then there's a little checkbox if you maybe don't want to use an image use a video there's a video and you could upload other variables and then some color options some variations and each of the components is built in this way you create templates here are some of them that we use that maps to the original project plan and all of the components that we had designed as part of this process a column, a cover page a chapter title and then you build up the stories and nest all of these things and they can be dragged around and opened up and you can see clearly which template is being used for each each story I have gather content open in another tab we can poke around if we have a little bit of time you're interested in that any questions so far? gather content in this part is the color indicating the status of the content it is, yeah totally so you can set deadlines on those pieces of content as well and you'll get a little some columns are hidden here but it will tell you when the content is due you can start to get alerts and there are other interfaces that give you a visualization of where all the content is at in the workflow state is 30% in editing 20% is done and 10% live on the website you can also assign content yes there's also rules for who can move things to different workflow states roles other questions? we're building a static site it's like the good old days you cut up your images you're slicing and dicing now images are responsive you need like a million and a half different images hand resizing and coating them all but, right? so it wasn't a problem it wasn't a huge problem initially but performance you don't want to be delivering really high resolution images to mobile devices and if we're putting this system in the hands of editors we're asking them to like photoshop and crop things and they need to look up all the image sizes and like crop stuff exactly and maybe they get it wrong and it's not going to fit in it's a nightmare you got to like jammed up with like this kind of thing to be able to get all of your all of your image sizes so what did we do? we used an API driven image handling solution similar to how Drupal has this image cache thing it's like a third party service and it allows you to query to query that that service so this was really cool we chose cloud image for a couple of reasons one, cloud image lets you perform operations on an image that you can pass via a URL so as we had the client uploading all their images into gather content we could then call those images via cloud image and the URL where it lived in gather content and perform resizing operations on it and deliver it back into the templates additionally they have a JavaScript library which let us write more terse code we just finished up so that there's a bunch of configurations where you can set default image sizes at various break points and then you can use them so this is what ends up getting rendered out in the browser for the image we're just passing these parameters and then based on the break points it's dynamically taking the source and flipping it out to an image and it's taking these criteria and passing them into the URL parameters to be able to get the image attack from cloud image so the source image were there any limits on the upload size like it's on a new URL so what are we uploading it at some yes, you want a high resolution image to start with so that you can downsize it to the smallest sizes and have it be as large as possible and some of these images and you can set those limits inside of gather content on the images and put help text and recommended resolution in pixels and there's validation as well but but then the images are in there and you can call them back and for some of the big cover stuff it's really quite big so we had different sizes for different different users so you upload that to gather content and gather content is configured to what's the size limit on the original, is there a size limit or not it doesn't matter a ton regardless of the dpi, it's the number of pixels and that we're really concerned about and we want to make sure it's not too small and not too big and at the end of the day our client is sophisticated enough and they have a digital asset management solution there is a bit of like handcraftiness to this whole thing we're talking about storytelling experiences they had a even their content team and content writers new html and so that was a big part weighing into the decision to use gather content and some of these features too because we knew that they would be able to like maintain those standards so what are the results look like here is the URL for the hub which you can use to launch out into those those different stories it is insights.bamsf.org and here are some examples of the screens on tablet just for atmospheric the work was a webby honoree which we're very proud of being a part of and here's how it looks so this is the site it's in a lot of ways exact or very close or adapted to some of the designs we saw earlier the initial text that did all that like baby stuff we estimated out and the client was like that's not that important let's not do it but because we had such a transparent process with them we were really able to trade off to get the best product possible and get as close to the designs and the feature set that they were looking to be able to tell this story ultimately we used foundation as the framework front end framework did you include the JavaScript? yes so we included some parts of the foundation that's selectively as well as additional libraries we can flip over later and I can show you all the stuff so you're getting a little bit of a sense of it this little video side by side there's a prototype on the left that they had built in their abstract pieces and then there's the website that we put together it's mostly the same we figured there were additional interactions that needed to happen where people that they clicked on an existing link would need to get popped back up and so there was a lot of kind of figuring out how to fill in the gaps once it came into that level of interaction design what did we learn? well we learned that we have really used gathered content quite unconventionally I had an opportunity to chat with the CTO and the CEO of gathered content about six months ago and they were like well no one's ever done that we were like well we have so we're probably we're trying to work on a case study with them to prophetize there was a requirement the client wanted to have which really given the scope we weren't able to realize they wanted to have social sharing for different parts of the page so if you got it's like one big page right you got to this part you just want to share like one part of the story you put it on Facebook and come back to that part now all of those tags are in the meta information and they're in a static site they're not variable you can't have call backs to rewrite them so that was something we couldn't do we could have done that if we had built the site in React for example which would have taken more time and energy and was a little bit outside of our wheelhouse at the time and you know there's some tradeoffs as well we were able to build really quickly and onboard the client and they were able to use tools they were familiar with with twig they wouldn't have been able to maintain a react application and but you know there's some performance benefits we could have gotten more more like dynamic loading of assets and progressive progressive enhancements progressive loading huge props ultimately go to our product owner who was a really big part of wrapping her head around what we were doing and how we were doing it and really trusted us so to lead them in that process and follow our advice and that was a huge part of the reason why this project was successful but the biggest challenge ultimately was that the lack of an integrated design process made it like sometimes we were the bearer of bad news where we had to say that's great sure we can do that or we can do that but it's going to be hacker budget and it would have been nice to and the client recognized this as well for us to have built a more like copier and comprehensive process all together we just published a case study about this particular project which highlights some of what I've talked about doesn't go into as much depth in some areas and more in others check it out and this is a link to Calistatic which is the open source if you want to play around with it and use it to build whatever it has some documentation as well and thank you see you again and questions thoughts feelings does Calistatic it uses twig it can it's a framework which uses certain conventions as such you can flip it out for different templating language you can and in different rendering engines as well so we use metalsmith as our generator but you know you could use this thing called JS Transformer so it detects the file extensions if you were to throw it instead of a twig a Jekyll it can handle that it's just a bit of light configuration and it does some auto detection so it's a lot of versatility in how you can how you can use it and it's all the same thing it's not like you need to download the PHP version of pattern lab or the you know which I don't know what their versions they have metalsmith is what so metalsmith is the static site generator it was developed by a company called segment in San Francisco they still maintain it they moved their site over to Gatsby at this point I believe it's in a node ecosystem it is all of Calistatic is the only dependency is node and you NPM install everything and it pulls it all together do you have any Docker containers Docker containers aren't necessary because you know all you need to do is install node and that's something you may want to be configuring on your system in the way that you want to we have considered it if you are interested in Docker type containers you can check out Lando which is the successor to Calibox another product we developed Lando we developed Calibox Lando is a Calibox 4 and Calimuna spun Calibox out to be more focused on its success as a product and the so the other founders of Calimuna have continued on to work on that which they have named as Lando but it's excellent we use it internally and well many other people do. Other questions? Yes How like you said you use gatorcon in a very specific way for your site would you recommend gatorcon for other usage versus building a site in dupel where you own this content versus paying your third party what's your cost benefit between using DAF or dupel Well the benefit here is that we can get started early and independently of the CMS existing on the content creation process it's a design tool for designing content and validating content and as such we'll create a better product and look at it as an investment that will get something better out the other side a lot of people look at it that way and then they ditch gather content once the site exists and people put their content inside the CMS that's what gather content has mostly been used for you gather it, you organize it, you figure it out you throw some stuff around and then you're like boom there it is then you suck it in and then you keep editing it in the CMS the pipeline is usually broken at that point How different from say content where you would Contentful Contentful Contentful is also API driven they have a slightly different model it was also more expensive for our purposes they calculate their pricing based on a number of pieces of content and so we evaluated that kind of like the scalability of how much content there would be over time and there's a in the roadmap we can decommission parts of the stories that are then published and they don't count towards your quota anymore so you could it would kind of break on the build now so we'd have to do a little bit more to make it work to say oh this one is moved to stop getting the stuff from gather content for this story it's like dead and then you can resurrect it later to do updates so that's a way that you could you know in this case use that model but if you were to have a website use it for all the content of your website and you had hundreds of thousands of nodes it would be rather expensive particularly because not all the pieces of content are like a node they might be broken up into all these little bits and that's what proliferates but something we really do like about it too is it's got this shared model you can have lots of projects in it it's not a cost per project so we can bring our clients into this and use the tool and as an agency it doesn't cost us like an arm and a leg for every project it's like a great value add for the clients to get to use another tool and we don't even charge them for it it enhances their project and their process and they can use this kind of thing and this workflow for other stuff that they're offering any kind of document something that's not going online for marketing materials for whatever it is and creating the fields is fairly intuitive it doesn't require a computer science degree or any like real technical knowledge of course a technical background is important because as you make decisions they have implications from the data modeling perspective and maintenance perspective but yeah it's we've been really happy with it so far in the right context you were to actually sorry do you still have your question I think you had your handle first yeah thanks I was quite interested to see this tree status of content readiness and does that have over revisions so if you revision you know every complex landing page and you're preparing the next revision and you get four or five things within that page you need to be revised it does handle revisions but that's another tier so we didn't go for that tier and and really like the sort of workflow states are what are being used so the revisions are not active in this account but you can't pay more to get active revisions and all kinds of more like in commenting you can comment on the content then and stuff Google Docs if if you were to you know face a similar project with the Drupal ecosystem as it is right now yeah over a bus paragraphs and then potentially a layup builder you know could be at play you've been coming to the same choice or the client in a similar circumstance and coming to the same choice time pressure if we didn't have the same time pressures we might have been looking we probably would have been looking at more of a react based solution and at the time Gatsby was not as mature as it is right now it's still maturing as well but if we had to do it today we would probably likely try to do it in Gatsby it's a great use case for this particular kind of single page app and the performance that is really required from it and it has an API centric view I don't know if it has a gather content built in gather content integration in the ecosystem but that's something that we could have built out it was something we evaluated in the different solutions that we were looking at we had some concepts we had already built integrations with in calisthenic and this was was kind of up there yes sir so in terms of costs and sort of like the legacy or the technical debt choices I guess how does the balance work out I mean you're not hosting any of this it's all on netlify and netlify and this is a production website for one of the largest museums in North America and they don't pay a dollar for hosting they don't pay they don't have to pay for the netlify their free tier is very generous for me and we're not making it's a single page app it's all like one app people go and they look at a thing they're not looking at like 400 things so from the way that they calculate they are paying for cloud image is that expensive it depends on how you use it they're one way of cutting costs which we explored which is a trade off we could build it so that you get the images and then we hope we do all the resizing and then we hold on to them locally and then use those so we're not going out and requesting them all the time but the pricing model was pretty good so it was cheaper to pay them than to pay us to build that functionality and netlify being free it was kind of a no brainer but it did add additional costs because their legacy stories remained on Drupal 8 untouched and they continue to be hosted and there's a cost to that they did not bring over the legacy stories into the new model and that was the intent from the beginning of the project the bottom line though is that this is probably very affordable I'm guessing for in terms of hosting maintenance in someone going forward this seems like it would be substantially less expensive than a lot of options for hosting you've got some small stuff you want to put it up there netlify is super great if you don't need a lot of dynamic content of course really great their APIs are smooth and they have a build system so through their build system we're compiling our sass and we're pushing all that stuff up we're not pushing any CSS up to github netlify is doing all of that getting all the stuff from gather content parsing that and shooting it up to the interwebs and it has this integration with github which is great so you make a pull request you get a new environment do you do your QA process the same way? yeah we had a targeted environment on test environment and test that and so they could go there reliably and we would merge the test and that mirrors the workflow states of gather content all the content that's in test is on test and the new content doesn't get built out in that environment so you're only seeing the newest content based on the workflow states I think we're out of time but I appreciate all these great questions love to chat more