 Just about your requirements at this moment, but your requirements for the future. Not this future necessarily, good music, but the actual future. And you don't always know those at the time. Jamie, why is my slide not going forward? If you know future requirements, it's a good time to talk about them right now. Because the future applications and enhancements you want to make can affect the decision for the technology you're doing at this time. At the very end, Paul and I have a bunch of examples we're going to give you. Good and bad that we've experienced at Phoenix where we've made decisions and how they've come out. You'll see that there was one where we deployed Drupal, made a decision. Future requirements later dictated it was a bit of a retrofit. So had we known those future requirements at the time, we wouldn't have built it in a specific way. You don't always know that, and we recognize that. So if you know future requirements, it's important to share them as part of the initial build. So let's talk about some of the benefits of Drupal. You want to choose Drupal when you have content management needs, like you spoke about, multi-lingual, portals, file management, image galleries, news, events, content type theming, responsive, compliant, DK, there's a bunch of these types of requirements that fit really nice for Drupal. Drupal is a powerful tool that matches all of your requirements very, very well. So if your project meets those kinds of criteria, Drupal rises to the top very, very quickly. Customization would be an isolated component of what you need, or you don't need customization at all. Budget always plays a role. If you have a limited budget and a limited deployment time, Drupal will work well, because Drupal gives you things out of the box that can get you up and running quickly. Those are some of the criteria that we use to choose whether you're choosing Drupal or not. Some of the benefits of using Drupal include quick deployment times because you leveraged the tools that exist. It's very resource rich. Drupal comes with lots of modules, a huge developer community, patches and upgrades ongoing. You can hit the ground running with Drupal. You don't have to start from scratch necessarily. You get to start with something you've built or configured. Also, Drupal has a number of modules that you can deploy based on your need. These modules you can review and test before building them. So there's less unknown with Drupal. You can take a look at a module, read its requirements, you can even deploy it and test it internally to see if it actually needs your needs or not. You can do all that before you choose it so you can give it a bit of a test run. Drupal is really good for enterprise level clients. Don't think that Drupal can only be used for small brochureware sites. We've got lots of enterprise clients that we've been using Drupal for. You can't handle Drupal. We're going to talk about that a bit later. Drupal is used for all industries. I often get asked, what is the most appropriate industry for Drupal? And quite honestly, it's the entire spectrum. Association, secondary for secondary education, healthcare, government, private sector, technology, health. I'm going to say health twice. Health is important. You can use it for all industries. It doesn't matter. What matters is your requirements. Some of the use cases. So we've talked about this a couple of times already. Do you want to manage content? Or does your client need to manage content? That's a good use of Drupal. Do you have multiple content types? Different types of content that require unique layouts? Do you have multi-lingual requirements? We live in Ottawa, at least by lingual, but we've done websites with, in one piece, 86 languages. So multi-lingual will fix Drupal really, really nicely. Portal login areas, if you are from an association or a member-based organization or require extra net channel capabilities, Drupal is well-leveraged for that. You use the CMS component for the public side and password authentication and login area for all the unique content and tiered content in the backend. Of course, Drupal has UK compliance capabilities, SEO capabilities, responsive theming. And, basically, you're looking for a website. Now, what are some of the drawbacks of Drupal? Depending on what you're trying to do, Drupal comes out of the box with inherent workflows. You can speak up anytime. I just don't want to make you feel like I'm a bargain. I don't know. Inherent workflows. So, depending on what you want to do, you're going to have to follow those workflows or change them. That could be a drawback, depending on the capability of your team or your vendor. Future enhancements. Again, we talked about this with the wrapper future. You have to think about your future enhancements. Will Drupal be the right solution in the future? If you know those future enhancements and requirements, and it's a no, then you don't want to have to rebuild something. There are updates required, as with any software. Drupal requires updates and patches and releases ongoing, and to be secure enough to date, you shouldn't. Yeah. And there has been problems with an upgrade process. I know Drupal 8 is looking to solve that. But typically, if you've gone from Drupal 5 to 6, where we started, 6 to 7, 7 to 8, it's a rebuild. So it's, you know, you get locked into the version that you're on. So that's Drupal. One thing I forgot to mention. If you have questions at any time, just ask me. This is not a chit-chat at you. Just put up your hand if you have a question or interject where necessary. I'm just going to comment, too. Just about that. Good job. When to choose custom? So we talked about Drupal. When do you choose custom? To build a custom application, which means starting from scratch, you're building it in a framework like Lareville or KPHP or anything, but you're starting it from scratch, you have to have a project that requires pretty much a 100% unique workflow and functionality not offered by any existing commercial, off-the-shelf product. So a product. Nothing exists out there that you can leverage. So you have to go custom. It's almost forced into custom, because you can't leverage anything. At least to the point that it makes sense. Maybe you found a tool that gives you 20% of your needs. That's not nearly enough, right? Maybe you have to build custom because of that. The site has a long life expectancy. In our experience, when we build custom applications, they're so tailored to the workflow and requirements and functional needs of the client that they last for 10 plus years. We can enhance the number one, but the base application we build lasts a long time. So you invest the time and money in building something custom and tailored so it's going to last for a long time. Typically, custom applications are enterprise-class applications. They will be used through the business. They will be used every day by certain departments within the business, multiple departments throughout the business, because you're building it to solve business problems. Workflows, automation, streamlining, etc. And so essentially when you have a heavy amount of customization required that's not well served by any cost, you have to go custom. So some of the benefits of custom, it's a really tailored solution, like a nice tailored suit, it fits your needs and requirements to a tee, it looks good, it fits you perfectly. You're not fighting with the CMS and the way it works, trying to force the CMS to work in different ways, and you get exactly what you need right away. Typically it's nice and stable, long-term, if it's well built, because it's built to meet your needs. For the most part, in our experience, we've seen excellent ROI for our clients who have invested in custom applications. We've had a client which we'll talk about later who saved millions of dollars in the first six months of launch by implementing a custom application. That's how much money it saved them. So they can be cost-saving a lot, but they can be good cost-saving measures. And it's typically an enterprise tool. So how do you determine if you need to go custom or durable? Well, if you need a specifically tailored solution where there is no costs available, commercial off-the-shelf tool, you go custom. See to the art application that doesn't exist already, you typically have to go custom. If it needs to be precise and follow a very specific workflow methodology that is internal to your business, it typically has to be custom, unless you're willing to compromise all that and change your processes to work toward a tool. It has to be custom. You're looking for tailored growth. You know that on-going, your future requirements will require very specific custom implementations and enhancements. And let's not forget that custom costs more money because it takes more time to build and it takes a lot more intensity because we're not giving ourselves a leg up with starting with the framework like Drupal. Everything is from the start custom. It's going to cost you more money in time. We always have to top budget because if you don't have budget and time for Drupal or for custom, sorry, then there's really no use talking about it. You're going to have to compromise your requirements of workflow to fit with the tool at Drupal because the budget is for custom. Well, there's a longer build cycle. Obviously, because we're not leveraging a tool and starting midway. Depending on the team that you're working with, whether it's an internal team or a vendor, there could be a high rate of error and inefficiency as the team has to figure out how to build things that are native to Drupal like user profiles and login, file management, all that kind of stuff that's out of the box with the ways. All that stuff that's out of the box with Drupal that you can just use and tailor as you need to build a custom. You have to think about how to build all these features. You're building every single piece of it even if on a framework like Narabelle you get somebody saying, do you still have to build them custom? So if your team isn't used to building custom applications and it's their first time out, be prepared for a lot of starting over and we've seen it happen. Higer class. With all this tailored solution you have to have more time and effort to build so it costs more money. Often you'll have to have a reliance on the vendor that built the proprietary tool for you so they're the ones that know the tool you're going to have to go back to them for and that could be good or bad playing on a relationship with the vendor. And then any of your enhancements on going will also be custom. If you built the custom solution you can't then leverage Drupal for the enhancements you've got to keep doing everything custom so the cost is relative there. So we've done Drupal we've done custom applications midway in between when you can actually take a tool like Drupal and customize it to your needs. The best time to benefit from this is when you get a project where a certain portion of your needs are well met through Drupal. There's content management needs, there's image management needs, there's maybe the login area, there's lots of needs that suit Drupal well, multilingual, perhaps e-commerce, solar search. All these things are well served through Drupal but there is a component that requires tailoring and customization. Perhaps there are tools and modules that Drupal offers that you could deploy and customize those or there's nothing existing that you have to build it yourself. You have to have a conversation whether it's with your client if you're a vendor like us or with your team if you have an internal web team about these nuances. I don't know if you're going to go through it but I just wanted to find a factor of what you call just Drupal and what we were calling here now, custom Drupal is that a lot of the modules that come with Drupal you can take them and you can keep them a bit to make them do what you need them to do but there are components to a lot of client's businesses that this has to work exactly like a certification process or what not and all those things it's depending on your dev team they'll build custom modules and they'll build workable all the way around that but with most of it We have a good example of this later that will show you like some real world examples where we made the decision to choose Drupal and then customize it for our needs. 80% of the client requirements were specifically well tailored to Drupal and 20% weren't so we did custom Drupal because 80% was met with Drupal so why start custom at that point? So what are the benefits of going custom Drupal? You get all the benefits of Drupal that we talked about you get a midway starting point Drupal gets you out of the box gets you with lots of features like login, wizzywake, all sorts of things ready to go this lets you focus on that 20% customization so you can get up and running really quickly and then focus your time and energies on that tailored part that needs to be customized and not the whole thing just the bits that need to be customized and you can get a tailored experience we've had great success using Drupal and then tailoring it and the client gets a really unique workflow and things that meet their specific needs and it's powered through Drupal what are some of the drawbacks? well they're again similar to some of the drawbacks of Drupal you do have a possibility of fighting with the code more so when you're trying to do custom solutions in Drupal because you're either using a module that you're trying to force in a different way or you're building your own module that then has to integrate with Drupal for the last 10% which is often the longest so if you have 10% customization that can often take 90% of the time to get done so you'll spend a little bit of time knocking your head up against your computer because that last bit is the toughest bit to customize there is a concern with update compliance so if you've done custom modules or you've changed modules and then you deploy your Drupal updates how do those things match together and how do you make sure they don't break or you should have passed this now but I feel like I need to say that and then of course integrating your custom work with the overall Drupal install can have its challenges if you don't know what you're doing any questions so far? everyone's following along, okay great anyone need more snacks? so there you go we've gone through some of the benefits and use cases of Drupal custom and Drupal custom essentially what we're saying is sometimes a real heart to heart with either your dev team or your client to go through what are your requirements now what are your requirements in the future where are we best served what meets your requirements best what is your time run, what is your budget all these things play a factor and we always talk about having conversations we sit as a team, we get a project in we go through the pros and cons where it's not evident very often we get projects that are very evidently perfect Drupal solution often we go back and forth on what would be the best way to leverage this because what we don't want is for clients to hate Drupal we don't want the developers to be mad at them when they're trying to support and build projects we don't want this kind of frustration around web projects you never want to make the project fit the tool you always want to make sure that based on requirements you choose the right solution and then you will avoid this agro alright any examples for you, does anyone have anything to interject any questions so far security, can you talk to security in those three scenarios sure so with Drupal you've kind of got an apparent security you've got a huge global team working on modules there is a downside to that is that if there is a security flaw there's a whole global network of people that I know about so you see a lot with work-pressed with Drupal the bigger CMS is that in terms of if you're a client the global site doesn't get your updates security is employed immediately then you tend to be a target because you're on these larger CMSs with custom you still have the same security risk you have what's called security by obscurity depending on what you use and how you build it people don't necessarily know how to get into it because you've got a custom module that doesn't mean you're exempt from security at all so I'd say that security standpoint it's easier to manage when you're with Drupal because you've got that community with you if you're going custom you're relying on either your vendor or if you're a client you're a third party person community doing it on your security but that's why you're trusting so the web vendor would have to practice best practices and security if they're doing a custom application if they don't know what those are then you're leaving yourself open and vulnerable to their knowledge really good custom application they have to build a security component with it or with Drupal it comes more inherent did that answer your question anyone else okay so we've got some examples of projects that we've worked on at Phoenix the first example is Nokia Nokia is a perfect Drupal client in that all their requirements meet Drupal CMS they want to manage content they have multi multi languages they have multi sites they have dispersed geography multiple publishers faceted search they're hosted on Aquiat everything they want to do it's a massive site it's huge enterprise yet it really is simple in that it's really a content management solution so we manage and deploy and build on the Nokia platform in Drupal 7 and it's perfectly tailored to content management there are no other unique needs for this website within Drupal there's a lot of unique needs but in terms of the fact that it requires managed content do you want to talk to any of you in Aether? no it's a good fit for Drupal perfect fit for Drupal this is an example of a client where they're an association and 80% of their needs are met through Drupal they want it to manage content they need to have a login Drupal provides that they want members to pay their dues Drupal provides that it has a member database you can give them that it's got news, images, galleries all that kind of stuff that's all Drupal they wanted to be able to allow the members to manage their certification these people have to show that they maintain their certification over time they had to be prompted to say you have logged in and now you need to show us it's time for your certification reminders as you log in to have your certification and you had to then upload proof that you've done your courses and there was this whole nothing in Drupal could satisfy that workflow such a unique workflow had so many unique components around it there was nothing we could leverage so Paul built a custom Drupal so we deployed Drupal built a CMP certification management feature as a custom piece in Drupal this you can't see very well it's supposed to be all fancy back end data stuff this is the NavCanada project I referenced it earlier we built this in cake PHP in 2008 and we launched it in 2009 this basically takes all of NavCanada's hiring for air traffic controllers and flight specialists it automates it online where it was previously a manually based process that was a big deal at the time when we launched this it saved NavCanada 1.1 million dollars in the first six months of launch and two hires this is a tool that NavCanada to this day still uses every single day both the admin use it in terms of the fact that prior to this tool NavCanada never knew how many applicants they had where people were in the process of applying for an air traffic controller if somebody in Gander five people in Gander are going to retire NavCanada didn't know if they had enough people in a database ready to fill those positions they didn't include where anybody was one of the biggest problems they had was that they didn't know they would have 20,000 or 34,000 applicants a year and at the end only 200 were making it through to the training they didn't know where they fell off was it at the psychometric testing was it in the interview second interview first interview medical where were these people they don't know how to process no idea because it wasn't in a database NavCanada uses this as a business tool now in the first year we had 20,000 applicants they know exactly how many people are being deployed to Gander and all their different towers throughout Canada who's in what stage where they're falling off in the process over two years so they can make business decisions about that this is a specific, specific, tailored solution that we couldn't have leveraged any path for on the front end and the candidates get to log in prior to this tool candidates would call two years in where's my application what do I do next what happened with my interview like they didn't have a clue candidates each now have a unique login it's got a tab thing at the top or they can see you're in phase three you've passed oh it's pending interview please respond to an interview date or something it's all automated no more phone calls candidates are well informed NavCanada uses this tool to make business decisions this is a perfect example of a custom application okay this is an upgrade screen this is a project that we built in Drupal and this is a bit of a back end screen built in Drupal perfectly suited to Drupal everything they said we were like ding ding ding ding ding bells and whistles are going off this is Drupal no problem we built it we built it and everything's great a year or two later they make an amendment we decide that the amendment can leverage the web forms module in Drupal no problem this is great this is where the requirements perfect fit a year after that they come back and say actually this web forms module that we're capturing all this data for needs to do this that this that this that this that and that's when we realized we should never have built this in web forms it's not the right tool or module for this had we known their future requirements we would have built this as a custom module to meet all their future needs we didn't know that at the time so what happened the client ended up having to compromise on their needs because they didn't have the budget to rebuild this as a custom piece so they just changed their requirements it happens all the time right if you don't have a budget for custom all of a sudden quickly like you want a new kitchen it's going to cost you 100,000 all of a sudden you think okay I'll just reclaim the covers like all of a sudden you change your requirements to meet your budget right that's what this is yeah it was one of our appropriate examples I'm going to get into a second detail you can just put a comment at the box and put forms on the site that you can fill out right and you can make it multiple choice you can add textiles whatever there's also a part of it that you can fill out your own custom components and you can make your own client a question that you can ask to your form so that's kind of the property level so we kind of went that Drupal ended the box with a slight tweak to the module and as Jeff said that's kind of where we fell short when they decided to change their future because they wanted to do more with it it's like well we could have made that fit into the box for a bunch of time and now no longer fits right whereas we went custom Drupal and filled their own questionnaire application that upgraded enhancing elements easier the issue is more the existing units are there right they have if it was something like 10 or 20,000 patents that log in and use these forms and try to enhance it with my form move that in which it's used as a headache I feel like maybe we have a comment from the seats this is my team here part of my team and I feel like they want to jump in and say style and I think this Drupal could have been avoided we had that conversation in advance of like where do you guys plan on taking this it takes off the way you want and if you had the pie in the style then you could have what you want because if you can have that conversation just have a glimpse of what they want or what you want then you could have a look no heaving we had the exact same issue with public works so we did the system on web forms and then they would not scale that out at the very beginning we had a discussion with the client that was the short term solution but the client was so adamant that no it has to be a web form short term for example do what you can as quickly as you can so when that happens what did you tell the client you know that picture where we had the girl talking you have to be honest and transparent and say this will meet your current needs but we had this conversation with the client but be mindful that we may have to rebuild this entire solution in a year from now if it takes off a lot of people will come to us clients will come and naturally they've got short budgets short budgets and short term frames and we'll say this is not the right solution for you but we've got to get up and run it quickly and then if it takes off we revisit the right structure moving forward and they understand that possibly a rebuild might be required I actually had this conversation with one of my clients and what I was just happy to say is that if you do go to a quick route do know that if you had to do it the right way to the end this is what your differences are and as long as they know about it then when they come back and say okay I'm going to do this okay we have lined up the forms when we talked about it it's the same thing we call it expectation setting with the client we always like to be if you go this route or this route here's what you expect a year from now and then they make a decision based on that did that answer your question this is our final example and after everything I told you about all the requirements that you need to make sure you choose Drupal we built a website, Grapevine if anyone is familiar with the Grapevine.ca right, the for sale by owner type thing we built this in Drupal and it is not a CMS so after I told you I had to meet all these criteria multi-cultural, multi-cultural types all that stuff, they said none of that and we still built it in Drupal and it still manages to serve the client well after 5 or 6 years we have many debates internally the motivation for building it in Drupal was time and cost plus the client didn't currently have a tool where they could see how many listings were posted when they were expiring when the open houses were how to approve new listings and all that kind of stuff they didn't have a facility to do that so this tool at least gave them all that in the back end their back end office was well set up for Drupal but the front end really isn't a content management it's a search, right? it allows you to search for homes and deploying something like solar or elastic search will help greatly with that experience and is required in this instance but that's a situation where Drupal wasn't really a natural fit but because there was time and budget considerations and the client had nothing that they could leverage to manage their business with so Drupal was a good fit and it continued to be for 4 or 5 years so there are exceptions, right? where you can build things in Drupal that aren't naturally a fit as long as you have that conversation with the client and they understand the limitations and opportunities provided by Drupal that is our top I would like to know how many people in the room by show of hands are developers how many of you are specifically Drupal developers? okay, so where do you agree you're a developer? we have a page in the web we're just starting to get into Drupal we're just going to do a part of that so we're we invest in Drupal 8 and we start to build okay, great how many people here are like project managers with business or sale business development or sales? of those people that are here is this presentation you're here to listen to this presentation because understanding when to sell Drupal is an important piece of information for you if that would be why this would be of interest understanding when to serve what technology for anyone who didn't put up your hand what do you do? oh, yeah we got a QA girl everyone else doing QA? yeah if anybody here on the client side that isn't a web developer like it's your client side but your developer like somebody who will be looking for web development companies and trying to figure out what to do with their own organization no, that's it okay, I just want to get a sense of the room you with the beer, what do you do? what's that, sorry? developer is developer developer is developer so does anyone have any questions or want to clarify anything that we've mentioned? the presentation will be made available at this link so you're welcome to I don't know if I can always email it out to anybody that can resist it go ahead this is more of a name you don't believe all I'm doing is how many projects are you building on to you? I think we're trying to go over D8 where the requirements fit in that we have a current project coming in that I want to go D8 but the team is convinced that it's got the right modules available for us to build off of and this should be unfortunate because by the time you start the project and finish it six or seven months goes by they might get there but at this moment in time so we are going D8 and have done a bunch of projects in it but it still depends on the requirements of the client and whether the modules are available, is that fair? yeah, so with this project we chose we have efficient chosen I guess you're the first it's great to do this because of that again it's the client time of the project whereas if you have the option to go to play I think it's a good time because even if it might not have a module in place that something that people say it does if you've got the time you can help build it, yeah so that's right we had that conversation when I was pushing 80s and when we would have to build a bunch of modules which we would love to do but we have to work to a deadline so we're at this situation where it's like if we had the novelty of time we would love to do that in a tribute but we have a very short time did that answer your question? yeah go ahead so our concern was yes, agreed yes like we saw that it's like you're stuck where it's like either we invest in building the modules or we invest in rebuilding the whole thing so I think you know how do you quantify both situations that's a valid concern the architecture of D8 is much more stable and better like you might say, the platform just for if you want to lift it yeah and what I would say to that is as long as you set expectations for a good job as long as you set expectations for budget and time with your bosses or whoever it is that's asking you and you've got that ability then absolutely go D8 because it's the platform you want to build on and it won't be decommissioned and supported anytime soon but we are often under the gun and have to serve client deadlines but if you can get that expectations set, absolutely I would go D8 go ahead have you fixed your projects about upgrading from 7.8? we talked about it yeah, we talked about upgrading from 7.8 I'm not to the opinion still that everyone likes to call it an upgrade but I think a lot of times it ends up being a rebuild and I could be wrong your situation is going to be different but I found a lot of times the client comes up and is like oh, we want to build a new version they don't just want to be on a new version they want to change the way the site looks or they want to add a new feature here a lot of times it ends up just being a rebuild maybe you can leverage some of the content or you can leverage some of the structure and the theme but a lot of times it ends up being a rebuild that's our experience anyways are you a developer? I get asked that a lot too like who just upgraded your plane and like oh that's that sounds a lot simpler than it is we need that easy gun we just sort of we have found that some stuff is made let's say slower yes everyone's focus right now is on eat any new thing and it's built entirely different so it's kind of exciting right so anyone else do you have any questions or comments? well thank you very much for your time today we appreciate it