 Hello, everybody. Going to interrupt your kind of 15 minute break that you're coming off of. So we're really excited to talk to you guys today. We are talking about a Drupal showcase project that we've done with a client of ours. It's within the ambitious digital experiences track. So it's a little bit of a less technical talk, and it's more focusing around the business challenge that we faced, how we collaborated with our client, how we solved the technical problems that we faced, and most importantly, the impact that it had on the business. So we have the pleasure of having our client with us today, which is super exciting. So I'll let her introduce herself. Hi, everyone. I'm Chelsea Teplitsky. I'm the director of marketing for Perforce Software. I'm Anthony Simone. I am a senior developer at Elevated Third. And on this project, I was the lead developer working with Chelsea. And I'm Kate Sawyer. I'm a senior account manager at Elevated Third. So a tag team this project with Anthony. So Anthony and I work at Elevated Third. We have a few other E3 people in the audience today. We're a digital agency based in Denver, Colorado. We primarily focus on enterprise level B2B kind of large scale websites. We've had the pleasure of working with a lot of digitally focused software companies like Perforce, which is fantastic. And we're really focusing on solving technology and marketing problems, so bringing those two pieces together. Perforce software, it solves the challenges that come with large scale development. So that could be large teams, large file sizes, or maybe just lots of files. But basically, our software tries to remove the technology barriers so that developers and designers can just innovate. So our session goals today are we want to kind of use the pillars of Perforce, scalability, flexibility, and reliability to talk about how Drupal is able to build a system that exemplifies those three items. And we're going to talk a little bit technically to give some background, but we're really going to focus on what this project looked like from the client perspective and what that story was and discuss real client side business processes and improvements that were results from this project. We're going to touch on each of those three pillars, scalability, flexibility, and reliability from the point of view of the challenge, the solution, and the outcome, both on the technical side and on the client side. So Perforce began as a startup in 1996 in the Bay Area. Today, we have eight offices worldwide. We've got over 200 employees and just over 3,000 customers. We have a 99% customer retention rate, and half of our deployment base has been with us for more than 10 years. Our first product was a version control or source control system called P4. Today, it's called Helix Core. And in the last two years, we've expanded our product portfolio, so we now have additional tools for developer collaboration, agile project management, and agile planning. Perforce is well known in the game development, semiconductor, and electronics industries. This is due to our ability to version all file types and sizes, including large binary files. So for example, with a game development company, they're going to have large video or image files. In 2017, our company was really poised for growth. We had private equity investments. We had a new leadership team, and we had some very ambitious goals. As we stood on that precipice, we realized that the website was a risk. Perforce.com was built on D7. It was a static site with an outdated design. And it had been built by two outside agencies at different times, so it was cobbled together by our internal IT team. And it was just a mess of conflicting code and style sheets and tons of outdated content. And it just took a really long time to make any sort of update to it. So the first requirement that we had for Elevated Third was that we wanted to build a site that was going to scale in the long term. As I mentioned, we had a new leadership team, and they had plans to really grow the company both organically and via acquisition. We had just completed our first acquisition at the end of 2016. We knew more were coming, but we didn't know when. We didn't know how many. And we didn't know what they were going to be. We were also rebranding our current products while launching new ones. And our marketing team had increased from five to 25 people. So based on all the context that Chelsea gave, it was clear that the product portfolio at this point was not clearly defined. And this was the discovery portion of this project. So we had no idea what things were going to look like in a year or in six months or even at launch, which at this point was a five month project timeline. So at this point in discovery, we were trying to figure out what we needed to do. We needed some kind of solution that was going to work for launch and be able to develop and scale with these unknowns. And just anecdotally, being in the full day discovery session we had with Chelsea and her large client team, we always go into those meetings and there are unknowns and there are questions and we discuss things. This felt like a lot of discussion, right? We were literally whiteboarding different product architecture scenarios. And we were thinking about, oh, maybe we don't just have actual products, but that they're umbrella categories. And they previously had this pretty strong branding element of a B. And we're like, oh, maybe we'll have the B. Maybe we won't have the B. There was just a lot of discussion. And so it was very exciting and at the same time a lot of unknowns. So essentially at this point for a scalability we had a goal, right? Our scalability goal was to build a Drupal solution that will fill the requirements to find during discovery, but we'll be able to be updated, handle new products, new lines, new business models. So essentially at this point our goal might sound suspiciously like, can you build a tool for us that'll do everything we need now and everything we need in the future, but we don't know what we need. So that's kind of the challenge. And Kate and I, all our emojis didn't show up. We didn't realize the emojis. We were like, ah. Yeah, it was obvious this was going to become, this is going to be a challenge. So at this point, from a project planning point of view, everything was kind of at red alert, right? Going through just some of the things you might talk about in discovery, like what level of variability or what level of risk was there at this point? And it was very high. Like how many unknowns are there? A lot. There are many unknowns. There were questions coming in kind of from all directions. And the single most important part of the project at this point, which was the content around the products, the product architecture, the presentation of the products, was the one piece that was the least defined. And from the project management standpoint, putting together the timeline is always one of the fun things to do at the beginning of the project. And we had a strict deadline, right? We were trying to launch this thing by May. There were a lot of pieces that were supposed to launch at the same time. And so we did not want the website to be the thing to hold that up. So we didn't have the luxury of waiting. We didn't have the luxury of saying, OK, well, you're going to have your architecture done in March. We'll just wait until then. Like we had to start moving. And so we saw a pretty big overlap with our UX and design process starting and even dev starting with some of these key decisions. So we had to really closely work together to figure out what are the pieces that we can identify now and what are the pieces that we can start moving and then just hope that they all sync up. And we're giving this presentation. So spoiler alert, it syncs up. So this was our context during discovery. We knew that product conversion was the top priority. And Chelsea also brought to us information that even though there were some issues with the current website, it's still was a pretty reasonable conversion tool. So there was a level of conversion that we didn't want to decrease on. That was sort of a risk, changing things without really knowing how these changes are going to affect the conversion that they were experiencing at the get-go. So this is our context. And if you've gone through some kind of technical discovery like this, or even on the business side, thinking of what does the product architecture look like? What does our business model look like? Some of these questions are probably things that would fly through your mind. Do products exist in a hierarchy? Do they belong to categories? Are there sub-products? Are there inter-relational relationships between them? How are these presented? How are they represented in the menu? Et cetera, et cetera, et cetera. All of these questions come up. And typically, in a discovery process, to build out some sort of tool to model business's product architecture, we need to have answers for all these questions. And we didn't have answers for any of them. So we needed to take a step back and kind of create a project plan that looked a little bit different from some project plans on previous projects. It was becoming evident to us that there were more unknowns in variables almost than requirements. So we started taking those variables and treating them almost like requirements, defining those variables, and keeping track of those variables just as much as the features, the explicit features that the client is telling us that they need. So this kind of brought us to the point where we were thinking that we really needed to start out with an MVP. We needed to start out with the simplest possible version of what this product architecture could look like at launch and then know that we are going to refactor this. Like plan for a refactor that comes in three months after launch, maybe two months after launch when these acquisitions come in, when all of the surrounding information changes, and when we can come back to these requirements. So we started with something very simple and we started with something that we were planning to change and planning to rebuild. So that gave us some really important context for how to think about this project at this point. Moving forward with the MVP, knowing we were going to change it. And from the client relationship perspective, I said earlier that we've been really lucky to work with technology focused companies. And I think in this case, when there were so many variables and we were talking about this concept of an MVP to have a client like Chelsea and her team who understood that concept and understood that even when we launched this thing, it can be refactored, it can be built on, and that enabled us to make quick decisions and have that kind of communication that we needed. So this kind of brings us to the beginning of our implementation strategy for how we were going to model this product architecture. We started to leverage some of Drupal's patterns that it sets up in a way that was going to help us in the future think about refactoring, think about these features on an individual level. We wanted to implement the items that were responsible for the content architecture in self-contained features because we knew we were probably going to have to remove and replace this entire feature at some point in the near future. So being really mindful to not create a lot of interdependent elements that are totally dependent on other parts of the code. So from a technical point of view, making modules very concise and very purposeful and separating different pieces of functionality across different modules so individual functionality could easily be swapped out and replaced. Another thing that was really important with our initial implementation was the data. A lot of times, with a CMS for some of the people who maybe are a little more technical here or who've gone through an entire project, the data is the thing that's hard to change. So being really cognizant of how we're using data and how we're modeling these behaviors with data so when it needs to change, we'll be in a positive place to change it. So essentially, plan for our variables. And at this point, our variable was we're going to have to rip this out and rebuild it at some point soon. So we're going to get, and this is going to be the most technical part of this conversation, but we're going to get into a little bit in terms of exactly what we built for handling, modeling this product hierarchy, and what the story of this specific feature was. So essentially, this is just a screenshot of the main navigation at launch. And you can see we have our top level nav items, and we have all of our products. Helix Core, Helix Forget, Helix ALM in the navigation. So we decided to use the main navigation, the main menu in Drupal as the source of all of the relationships, all of the content relationships on the site. So we have products and sub pages, which in the next slide, we could see this red box. All of the products have landing pages. They kind of behaved like microsites. And then the pages in the sub nav beneath are just the items that were in the main menu below that main navigation item. So we were taking advantage of using one item in Drupal, the main menu, to model out a lot of functionality. This was easy. It made it simple for a content admin on Chelsea's side to create a new page, click a button that says Show Subnavigation. It was not flexible. So we were balancing the easiest solution that wasn't flexible, because at this point, we didn't know what the flexibility was that we needed to plan for. So there was no complex behavior here. And this worked for us, and it worked for Chelsea's team at lunch, and for a short amount of time after lunch. But quickly, like Chelsea was talking about, there were more products. There were more product lines. And there were a lot more special cases where this simple implementation wouldn't suffice. So the site launched, and everything was going great. And then we heard from Chelsea in July. And she said, we have this top secret project Nordic. Sounds awesome. So they had acquired a new business that had to launch on the site in September. So we had to figure out how we were going to adjust the nav. She also said, and we all have another acquisition in the works, but we don't have all the details about it yet. Can't really tell you yet. But plan for it. So now we need to scale the architecture of the site and the navigation accordingly, both horizontally so moving into additional product categories as well as vertically. So adding on products within the existing category. So now we have some more specific requirements that we can work with. So this is just another visual representation of the problem that we had at hand and what we were trying to account for. So initially at lunch, we had our tier one item being the products page. And then our tier two items were all the products. And you can see our tier three items were the pages underneath in the sub-nav. So any subordinate pages. But then as time went on, products started to have different responsibilities. Sometimes products would be nested underneath products. So Helix RM would be nested underneath Helix ALM. New product lines had totally new unexpected behaviors that destroyed this kind of architecture structure even more. So we needed to build something that was a lot more flexible than this. So our solution at this point has kind of a two-part, two steps to it, essentially. We have the data side of things. And we have the implementation side of things. So first we needed to decouple the product sub-nav from the actual menu. So decouple the data architecture. Like I mentioned before, all of the content that Chelsea's team would actually enter in that was supporting this feature was tracked in the main navigation. So that wasn't supporting this new functionality anymore. And we needed to have relationships on an individual node level, an individual page level. So we changed the single source of this from the menu down to node relationships. So that was pretty easy because we had it all in one place and then we decided to change it to another. Since we built this component initially as one custom block in one module, just one thing, we could build a new thing that we could just swap out and replace it with. So we included one new component and one change to the data model. And it was a pretty seamless deployment because we could just push up that new component, then Chelsea's team had access to new tools that they could create new relationships. And the feature was changed. The entire data model behind the product architecture was swapped out for a different one. So this is some screen grabs of the current navigation. And as you can see, it looks pretty similar, right? Visually, it's not that different. But structurally, from behind the scenes with Drupal, it's built totally differently because these two items no longer are related at all. One of the main needs was the main navigation needed to be a totally arbitrary visual presentation of their data, what they want to push, which products they want to push, how they want to show those kind of visual relationships that might not necessarily relate and directly to their business models. So now they have a main navigation that is totally customizable and totally flexible. They could place items wherever they need to place it. They can configure the visual presentations in any way they need as well. And then the subnav is based on a new relationship that we added. So now we have a fully featured component with a complex implementation that actually targets the client's needs. So in terms of the outcome from the technical side of things, the project side, we spent a lot of time defining the unknowns and defining the variables. And we knew at the beginning of the project that if we tried to build a fully featured solution at this point, it wasn't gonna work because we were going to just be building on assumptions and not building on what the client actually needed. And this allowed us to have a very clean post-launch refactor into a piece of functionality that was very targeted to the client's needs. Yeah, I really think the product menu is a great example of how this site was built for scale. So today the web team can adjust our product menu and our product page hierarchy very quickly, very easily. And business lines can really display the dependencies and relationships between products, however they want to. So an example of that is our Helix Aniline product suite. We have three individual components and you can buy each of those separately or you can buy the whole suite as one. And so it was important to us to be able to convey that relationship both in the menu and then also on those individual product pages. And I think we were very successful at doing that. So the second requirement for the website was to make sure that it was flexible. We talked about that a little bit. But as I mentioned previously, the way that our D7 site was built, every single update, even small copy changes had to go through the web developer. And even worse, if we wanted to make a new page, it was like custom built template made from scratch. And so it became this huge bottleneck for us and we were literally waiting weeks just to make changes. Yeah, so ultimately our second goal with flexibility was just to create this system that would make the developers and the content admins, we want to make their day to day jobs easier. That's the ultimate goal. We want to give them kind of a toolbox of complex components and different pieces that they can put together to create pages and then really free up that developer to create new features and improve the site ongoing. And we have a couple more, oh, these showed up differently. So with response to this request from Chelsea, we were really excited because this kind of was a totally, totally 180 from what we were talking about before with a lot of unknowns. This is the kind of situation that Drupal is really great at. Flexibility is what Drupal does best and building out complicated data structures and deep data structures is something that Drupal really excels at. And it just so happens that well-defined, well-structured data is essential for building modular and flexible component-based design systems. So Drupal can build very deep and very flexible systems for users to use and give users a lot of power. Drupal loves component-based design and atomic design structures. So well-defined content is easy to manage. When content types have well-defined responsibilities, they have very clear intentions, then it's easy for content admins to know exactly what they need to do to target content updates or create new functionality or new portions of the site. It empowers content admins to create some very complex components. We created some custom theming on the back end to kind of make paragraphs component-based content editing a little more straightforward and clean. And some of the components that content admins were able to use allowed them to build very complex data structures on the front end. Things like tabs or complex sliders or referencing content from other parts of the websites. All of this became pretty trivial to a content admin. We were able to use atomic design to create a very flexible content system that also can be modified and extended in the future very easily. So we created a lot of flexibility that really empowered the content admins to do what they need to do and to build and create entirely new experiences on the website. Nice, we got the emoji here. So we've talked about the role before of content admins and developers. So after we built this new D8 site, we've really optimized what their day-to-day roles are. So content admins are no longer beholden to the developer if they wanna make a small change. They have this toolbox of components to really get creative with making new page layouts. And when you're a company like Perforce that has acquisitions and new products, they need that flexibility. And then you have a developer who is no longer just creating new page templates or doing content entry tasks. They're able to really look at the site holistically and think, how can we improve this at a higher level? So they're high-fiving each other. They're working together and their roles together are optimized. So this flexibility was really put to the test with the launch of a new product called Helix Team Hub, which the logo is not there. There it is. Oh, lovely. So Team Hub was a different product for us instead of focusing on large-scale development in enterprise companies. It focused more on the mid-tier. Team Hub is a Git hosting and code repository tool, but it also supports artifacts. And so we needed these project pages to have a slightly different look and feel than the rest of our website with different layouts and really highlighting the gooey of this product. We were directly competing with established leaders like GitHub and GitLab, but unlike GitHub and GitLab, Team Hub allows you to store your artifacts alongside your code and you can also have multiple Git repositories within a single project. So this gives you a single source of truth as you're trying to scale, as your products grow in complexity or as your repos grow. Oh, I'm sorry, I thought we had a different slide. Anyways, so basically, not only were our content teams able to build these new pages really, really quickly, but we had a very short time to launch this product and we got it done in days instead of in weeks. So this brings us to our third sort of challenge that we were working through for this project and that was reliability. And so Jupylate's been around now for a couple of years and I'm sure we've all kind of heard some of these new things that Jupylate bring to the table, but it definitely does create a new foundation for building Drupal. So we asked E3 to make sure that the website they built was gonna be something that our small web team could sustain and maintain on their own. We also wanted to make sure that it was gonna be easy for new team members to learn how to make these content updates and then even if a beginner content admin is going to the site, they could make these changes without worrying about messing up the rest of the website. We wanted them to be able to make SEO updates easily and then most importantly really give their website visitors so our customers and new prospects a consistent experience every time they visited the website. So our goal here was to empower pro forces, in-house developers, marketing teams, content admins, to be able to manage update and build their Drupal 8 application completely on their own, consistently. So these are some of the things that are probably buzzwords that have come up a lot. If you're a little less familiar with Drupal, you probably have heard these things talked about it. If you're using Drupal 8, then you probably are pretty familiar with these, but on the left side, things like composer configuration management, the release cycle are all really important new aspects to using Drupal when Drupal 8 came out. Composer lets you manage your assets a lot more explicitly and it lets you leverage completely unrelated PHP libraries in a much more standard way like the rest of the PHP community does. So it's a lot easier to manage your project using Composer than in Drupal 7, which is essentially just a big repo of all of your stuff. Configuration management lets you deploy specific features through code instead of through the database. So when we were talking about our refactor, our product architecture refactor, that was a totally seamless deployment. It was a push, a config import, and in about five minutes, that feature was on production, ready for Chelsea's team to jump in, change content, edit content. It was kind of a flawless deployment. It was one of our, this was a while ago, this was one of our first Drupal 8 sites, and it was one of the first large features that I personally deployed on Drupal 8, and it was amazing how smooth it was. So that was a really satisfying thing from my side from the development point of view. And then we wanted to kind of present some positive Git workflow patterns. These aren't really specifically related to Drupal, but give a good structure for them to take and to start using on their internal team and give them good patterns, good best practices to follow. And then the release cycle with Drupal 8 is really important because now with Drupal 8, every minor release is adding some new functionality, and then eventually a minor release will bring Drupal 8 to Drupal 9, right? So if your new web project, your new web system is built in Drupal 8 and is really thoroughly planned out and well thought out, you may never have to rebuild your system, right? Drupal 8 will be updated, eventually it'll be updated to Drupal 9, and that'll keep going. You can have one rebuild now that is essentially your web platform for the foreseeable future. There's not gonna be like any hard updates that require a hard rebuild. And then on the project level, these are a little less, you know, a little more softer things that we implemented, but we really leveraged Drupal's ability to do modular content. That's what Drupal really excels at. So we aligned SAS styles, JavaScripts, templates, all up with the way Drupal handles these component-based entities. So we had kind of strict rules about how templates are built, how style sheets are built, and then we were able to hopefully pass this off to the client side in the future and maybe they would keep using these patterns. That was the intended idea. Yeah. So one thing that was kind of unusual about this project and one of the coolest things I think is that after working on the site for so long, Anthony really intimately knew the site and what kind of in-house developer would be needed to support the ongoing maintenance and updates to the site. So we actually helped with hiring for Perforce's new developer. We developed a code test, we did code reviews, and I think that we were just really invested in knowing that this product that we had built was going to be well maintained. And so it ended up working really well. Anthony made a lot of guides to the site that the developer at Perforce was very invested in learning about the patterns that we had established and working within those constraints. And so we had an ongoing phase two project. The image on the right is what our Asana project looked like. So we were really cranking through a lot of tasks together. Anthony and Perforce's developer were on Slack. They were just very, very collaborative. And for me as an account and project manager, that's really the dream that the developers are working that well together. So that's a huge success story for us and one of the things that I think went really well and the reliability of the product that we built. So this is Jeremy and I working together. We look pretty similar. Jeremy may or may not be in this room. I won't give up his identity. He's yellow though. Yeah, so that was really cool. Like that they were just really working together that well. Yeah, and so Jeremy came on after the site was launched and we were working together on a lot of post-launch updates, new features, QA, that kind of thing. And gradually over a period of maybe about six months, maybe less, I can't totally remember, but the amount that I was doing was decreasing and the amount that Jeremy was doing was increasing. And we got to the point where we had a pretty complete transition, where the project now is Perforce's project and they're doing pretty much the majority of the maintenance. So that's Chelsea being really happy and that's Jeremy being cool with sunglasses on. With sunglasses on. Because he's awesome. Yeah, so just basically E3 really delivered. They built a website that pretty much put them out of a job and to their credit, they were willing to do that and we were just really happy with the end result. So since the launch, the website metrics have continued to impress. Traffic has gone up every quarter in 2017, so from Q1 to Q4 of 2017, total traffic increased by 249%. Our international traffic from Q1 to Q4 went up by 400%. And then our blog traffic, this is primarily organic and so it represents new prospects for us and it's an important driver of new prospects to our website and that increased by 33%. And a lot of that was driven by SEO updates that our content admins were able to make now much more quickly and in a much more agile manner. And then as Jeremy mentioned, even though the old D7 sites had problems, ironically it was a very strong lead gen channel for us, it was our most important one. So not disrupting lead gen was paramount to this launch and this represents our web-based leads for every quarter in 2017. So we've seen our web-based leads increase and then our conversion rate on the website of visitors to leads has increased as well. So at the end of Q4, we're at a 4.1% conversion rate. Now in 2018, we're at a 5% conversion rate and we have a goal to get it up to 7%. So just to kind of bring everything back together, we had a couple, I would say, the most important things that we took from this project. A couple really big takeaways. Just kind of reading this straight from the slide but don't try to solve the problems that can't be answered yet. That was a really, really important thing. A lot of times maybe it's easy to feel just pressured by the situation or the client. Like we have to have a solution and then based on what you know, you just make one up and then you build something and then that thing that's built isn't actually doing what the client needs to do or what the client's expecting because there wasn't enough information to figure out what they really wanted. So tracking the unknowns and the variables became just as important as tracking requirements and targeting MVP over guesswork became really, really clear in this project specifically because the example and the case study, the case that we had with this showed how much that provided a better tool for the client. And these can be hard conversations. Like one thing that Kate mentioned, a lot of these conversations were easy with Perforce because they were a tech company. The idea of what an MVP is or what refactoring means, all of those things were inherent in their vocabulary already. So that's definitely a really thing that made this a lot easier for us. And so those conversations might be harder to have with some clients, right? But ultimately demonstrating the value that this is going to return back to their project or their system or the money it's going to save has shown to be a clear way to kind of talk about it or to talk through this process even if the technical part is not as easily understood by the client. So the second kind of takeaway would be always build like you're going to tear it apart. Investing extra time into properly building functionality in a componentized manner, it's definitely gonna pay out. In terms of time for the technical team and in terms of money for the client side team. Especially if you want a project that's going to live and grow with your business, it has to be built to be able to do that. And the immediate refactor of an entire portion of the website, arguably one of the most important parts of it happening right after launch and being successful is a testament to this. This is everyone smiling together at the end. Awesome, so yeah, that concludes our presentation. We're gonna have a little bit of time for Q&A and if you wanna come up and talk to us, that would be great. So I hope you learned something. I hope that if you're embarking on a website project or in the middle of one that you're inspired to make sure that it's scalable, flexible and reliable and apply some of these best practices to your site. Elevated third, we're a sponsor of DrupalCon this year. We have a booth, 306. If you go into the main hall, it's right to the left. So we would love if you would stop by and say hello and meet some of the rest of our team. Yeah, thank you. Yeah, so we did talk about it a little bit initially and then eventually Perforce did end up using the Acquia personalization product and but that's something that they are working into the project now. So the sort of component-based content system is kind of allowing them to create these new blocks and just integrate into Acquia's Lyft platform that functionality of swapping out content, replacing content. And so I know they're just kind of starting up the campaigns now. Yeah, so if you guys have used Acquia Lyft before, the way it works is the first couple months it's kind of a ramp up period where they are collecting data from your current website visitors and then from that data you can create segments and then you personalize, as Anthony said, certain blocks on your website and so that's something that we're hoping to roll out this May slash June, yeah. Any other questions? Thank you all for listening. Thanks everyone.