 How to bake a cake, talking to developers, and scoping your Drupal project. My name is Danielle. I'm from Cold Front Labs. I'll get into my background a little bit later. Just a small little note, if you swing by the Cold Front booth, we are running a contest for Google Home. So if you want more information about that, come and see me at the end of the presentation and figure out how you can win that one. So I'm Danielle. I'm the communications coordinator at Cold Front Labs. Basically, a fancy way for saying that if it doesn't involve code, it ends up on my desk. So I'm not a programmer. I'm not a developer. I do everything, but honestly, I'd almost want to call myself a foreign explorer. I made a career change in the past year. I used to be a high school English teacher. I also worked in event management. I had a very small stint in IT for a political party, basically fixing printers. So this is not my field. And what's been really interesting is as I get into this field, seeing where communication barriers break down. I work with wonderful developers and web designers, but they speak a completely different language. And I've never been more certain of something in my entire life. The conversations that go on in my office, I only catch blips occasionally, and I'm getting better. But what I realize is I often come in the same place as the client or the organization. They're like, we need some help, but we don't really know. So they're trying to navigate this. And so I'm also trying to navigate it. So I'm a little foreign explorer into this world. So thanks for having me, guys. All right, you have a job. I need you to draw me the most delicious cake ever. If you do not have a pen or paper with you, because I realize I'm at a tech conference, please take out your phone or whatever. And I'd like you to Google pictures of cake and choose your favorite ones. So should I Google that? Google cake? No, we just have to Google them. Just like a real cake. This is the part. All right, now, turn to your neighbor. Have a little chat. Talk about if your cakes are the same. Do they look the same or are they different? Do you qualify a delicious cake in the same manner? Yeah. Now, cake gets people excited. All right. Odds are, you've all got things very different. So the way that we qualified delicious, the way that we envisioned our cake was all very, very different. Now, if I were to say to you, hey, I want the following cake. I want that cake to be three tiered with a one to two to two ratio. That's the high school English teacher. I want it to be vanilla cake inside. I want the bottom of the middle tier should have chocolate frosting with a caramel drizzle. Anywhere the caramel drizzle doesn't hit, I want it to have multicolored sprinkles. And the top tier should have a raspberry frosting. And there's gonna be one blue candle and I want you to serve it on a simple blue dinner plate, okay? Picture that in your head, right? You're probably all somewhere close to this. Sly variance, but a lot less diversity than what we had in front of us. So, the key to communication is, the key to success is communication. Now, I will get my lovely assistant, Melissa here, to start handing out cake because I wouldn't show you all these wonderful pictures if I'm making sure that you got something to eat. Mind the wrappers while I'm talking, guys, okay? I love that. So, talking to developers. What does cake have to do with websites? The entire concept is that when you're scoping out your website, you really just want to build a delicious cake. But how you envision that cake and how the developer envisions that cake might be different unless you actually talk about it and break down the specs. Now, that communication disconnect that I was talking about before, let's talk about why that happens. Developers are lovely, wonderful people who love what they do, but they live in their own heads. And I say that with a great deal of love. They're passionate experts who speak their own jargon. They list off acronyms and expect to know exactly what they're talking about. So be aware of jargon, and when you are chatting with them, stop them and ask them to break things down. They are experts, so they should be able to break down these acronyms for you, okay? Secondly, they know the trends. They know where the field is going. If they're pushing for you to do something in a certain way, it's likely because it's best practices. It's likely because that's where the field is heading. And they also wanna be really proud of what they build. I often see times where the client's like, oh, let's do it this way. And it's like, eh, I don't, not that I don't wanna do it that way, it's that this won't work for you in the best way possible. So you do have to sort of put a little bit of trust in there and that these people really know what they're doing. Now, here's the other thing that happens. When you're scoping out a website, you think, website, everyone's got one of those, okay? Same as when we bake cake. You think, I got some flour, some sugar, some butter, some milk, some eggs, little baking powder, flavor, let's go with chocolate. Mix it all together, bake it, decorate with some icing. Voila, cake, right? That's simple. Here's what a developer thinks if he or she had to bake a cake. Where are you sourcing your ingredients from? Is anything coming from another country? How will the ingredients be transported to you? How do you plan to mix the ingredients together? By hand mixer, electric mixer, stand-up mixer, and the oven, what year was it manufactured? Is it convection? Actually, what is the heat source? Is that actually electric or gas? And any outstanding issues with your energy provider? It just keeps going because they are thinking about every little granular part of how this website for cake is going to function. So it's not that they're trying to talk circles around you, it's that these things matter and having answers to these questions are going to get you a better product in the end. Scoping your Drupal project. When you do, comes down to the five basic questions. Who, what, when, where, why, okay? And how we can throw in there as well, although it didn't fit at W. So when you're going to scope out your Drupal project, ask yourself why are we doing this, okay? And find a goal. So often it's why are we getting this because we need to have a website. Well, no, what's your aim? So one or two sentences about what this project aims to achieve. For cake, just to sort of set this up for you, the first purpose of a cake could be, I want the most epic cake ever. I want to impress people. That's going to be very different than a cake that's concerned with dietary restrictions. So they're different goals and they're going to be very different products. The same is the case when you're scoping a website. If your organization's goal is to expand your reach and create a platform for engagement, that's going to be very different than a website that wants to complete online transactions. It's not that these things are mutually exclusive and they're not going to happen on that same website, but what's the goal? What's the focus? What's the functionality that's going to be most important? Time and budget, okay? These always come up and they are the difference between the cake on the left and the cake on the right, okay? Be very clear about when you want to go live. We've had instances where a client organization wants this massive website with all this functionality and they're like, I would like it in 30 days, okay? That's not realistically going to happen. So making sure you have a clear go live date and it meets the functionality that you're looking to have, okay? Also, the big money ticket question, budget. I understand when you're going to a shop and you don't want to give them your budget, but give them a range, okay? So we know if we're talking about a $10,000 website, $20,000 website, $100,000 website, those are all very different things that when you're trying to get an estimate or a project scope down, it gives you a sense of, what can we realistically build here? What is it for? Who is your user base? So if we are building a website for kids versus for government clients, it's going to be very different. The same way that when you bake a cake for a birthday party versus a wedding versus the muffin Christmas, those are all going to be very different things. So we need to know about your user base. So telling us who's going to be visiting, not just your numbers, so often we'll get traffic, right? Which we do need to know, but who are they? How are they expecting to be engaged? It's going to have a huge impact in the way that the website is built. Functionality, okay? And this one I've titled where and how to start off. And the where here I want you to think about, if we go back to our cake analogy, what do you have in your kitchen within your organization in order to build or bake this cake, okay? I need to know if you are coming off of an existing content management system. Are you looking for a migration? Are we going to do it? Are you going to do it? Is someone else going to do it? User management, are you expecting people to log in? This is the one I see creep up a lot when people are scoping out a website and they'll be like, oh yeah, we wanted a calendar that everybody could update and put events in. Okay, then you need user management. People need to log in and be a identified user for that to happen. And that's a very different website than a brochure type website. How available does your website need to be? If there is a apocalypse, does your website still need to be up? Okay? Because there are instances in clients that has true. If it goes down and you have cash data, that's fine, great, okay? But we need to know what those expectations are going in, okay? How much traffic do you expect? Any third party integration? Is Drupal need to talk to anything? There's this assumption that we can make anything work because technology is so miraculous and wonderful but some things are easier than others. So putting those on the table right away is going to make your Drupal project go a lot quicker and better. Are there any technology restrictions? So what I'm talking about here is often you'll have an organization who is so accustomed to a certain platform. So for example, somebody we were just working with and we're like, we need a windows-based hosting solution. I know you guys love Linux, but it's not happening. So making sure you find somebody who fits into that integration is really important for both you and for the development team because you don't want to be butting heads about this the entire time. And hosting requirements, again, are we hosting it? Are you hosting it? Is somebody else hosting it? And the reason I bring up this list of questions is because often on calls with one of our developers and myself, and we start listing up these questions and they're like, I don't know. I don't know. And it's just before you go into those scoping meetings, having a conversation with your internal IT team to get the answers to these questions are gonna make moves move a lot quicker. Fancy functionality. These are like the bells and whistles. So if you think about your cake, this is like the candle, the fancy platter. If somebody needs to jump out of it, if it's chocolate, if there's gonna be sparklers. What are the things that the website is going to do? Is you don't want a website that does everything because that's just overwhelming, right? Is this something that needs to accept donations? Are you looking for advertising? Is blog really important? Or is it just this little sort of side project? So ask yourself, what does the website need to do to work best for our user base? There's a few givens that most people want, but sometimes you need to assess it for your content strategy if that actually makes sense. If you have a blog and you write two posts a year, probably don't need a blog, okay? So really assess what functionality you need going in. Don't just have a blog because everybody has a blog. And design. So developers, bake cake, they rarely decorate it, okay? They are the kings and queens of building really beautiful shells. And content and design can really fall by the wayside because it's kind of this, well, like it'll still work, but nothing will be there. And it's actually one of the most important parts. Branding and style guidelines. So putting up front what your style guidelines are. If you have a style guide, send it to us. That's wonderful. Even when we're scoping stuff out, even if we're just in conversations about an estimate, it gives us a clear sense of how much design needs to be done or doesn't need to be done, okay? You also want to establish who is responsible for these things. Is it internal or externally expecting someone on our team to do it or somebody on your team to do it going in? Web design, same thing. And also content authoring. Content authoring is another big one because you don't necessarily just want to dump all the content that you have on if no one's read it, gone through it, reviewed it. So again, is that happening with the development team that you're talking about or is it something that your organization is looking at doing? Also, if you're looking for a little extra help on your content and design stuff, our lovely colleague, Miss Melissa, who was handing out the cakes to you tomorrow, she's actually doing a presentation on choosing your logo colors and how that affects design and accessibility and all that stuff. So you can check that out Saturday morning if you are interested. Things to watch out for. So this is a little chat I had with our developers in-house and just things that they've seen keep up over and over again when scoping a project. This is a website scope we received, I think about six weeks ago, I'm not gonna say it's on Boo, obviously, but this was the scope. We got an email, it's like, hey, we're looking for a new website. And I'm actually gonna read this slide to you. I know it's like the cardinal sin in PowerPoint presentations to read you the slide, but this one's important. This is Ena. We want to design our current website. We design our current website. We require a more effective information architecture and a more versatile content management system. In addition to aesthetic appeal of the website, the new design must be accessible to all. It should be intuitive, engaging, responsive, adaptive, interactive, easy to navigate, mobile-friendly, fully searchable, and less time-consuming to update by staff and officers. With a newsfeed and an interactive calendar and email distribution and discussion group options as well as opt-in and opt-out procedures, the new design must simplify all communications with members. Could we get a quote? Thanks. Yes, we'd love to work with you. But this obviously caused a lot of back and forth with this potential client. And a lot of like, oh, we don't know. We're not sure. The person who knows that's on vacation. So it just, it really quickly wasn't clear. And this could be, for those of you in the room who do know, this could be a really small basic website, or this could be a massive entity. It's not clear. So really avoid the dumping everything into one paragraph. The next slide, this is better, still not great. But this is one of the places where bullet points can really be your friend. Because when a firm or an agency is going through to estimate everything for you, we literally go bullet by bullet and it's like, okay, that functionality will require this level of work and this is what we need to do it and it breaks everything down. So this is my slight rewrite of what they sent us. And you know, you have to flush out that goal. And I'm making assumptions here as the agency that perhaps are correct, but I'm taking my best shot. If the client or the organization actually does this, things are gonna be clear and we're not gonna have that disconnect in communication. And just, this comes right from the top owners of our company. These are really dangerous words that come up in scope meetings yet. They're these sort of off-handed comments where you're talking about how the web application is gonna be built. And it's just like, oh, we just need this. Oh, and this, okay? Functionality takes time to configure. Nothing just happens, okay? There's a lot of modules and code we need to get written to make that happen. So examples are, oh, and just a calendar for everyone to update. All right, just throw that on there, onto the website. When this could actually require user management, it could potentially require third party integration, things that are much more complex. Another one we had recently was, oh, we just wanna collect some feedback. Okay, is that a form? As I'm like, to fill out a form, is it a form, like a discussion form? Is, are there comments to the pages? What is your organization looking for? Cause those are all very different things. Additionally, do you wanna track data about the user's giving feedback? Do you need to know who they are, when they said it? Do you wanna be able to engage with them right there? So these are all things that spiral and snowball very, very quickly. So coming in with clear expectations and ideas about how you want the stuff to function on your web application is really important. Stop worrying about Drupal 7 or 8. In every presentation that we've had recently with clients, it's like, so Drupal 7 or Drupal 8, which direction should we go? Or they'll come in and say, it's gotta be Drupal 8 cause it's new. Every time I've heard anyone on our team feel this question, it's like, let's see what your business needs are. Let's look at exactly what you want. Drupal 7 is stable, it's well supported, there's a lot of modules. It works great. Yeah. Okay, Drupal 8's getting there. Things will be there soon. But Drupal 7 isn't going anywhere. So if you want something that's stable right now, likely gonna recommend 7. We're looking for something a little more innovative. 8 might be the answer. But if you find a good development team, you should be able to trust them to make that recommendation for you. All right, that's your baker or your development team. So I don't wanna start a fight. Gotta be very careful with this one. But site builders versus developers. There are lots of projects that site builders are awesome at and they can build just fine. They're excellent at configuring Drupal as it comes. They're masters of that interface. But they typically don't have a full IT background. They may occasionally hack code, but they're gonna work with Drupal as it is generally. Okay, I'll hide behind the podium in case anyone's throwing at me. Developers, they're able to write custom code. They're able to write custom modules for you. And they're able to make Drupal talk to other web services a little more easily. No going into your project, how complex things are looking to be. And realize you might not have an IT background yourself going into it, but look at, are we looking for a sort of a run-of-the-mill content management system? Or are we looking for all these special functionalities that aren't typically done? And you're gonna be able to see, well, what do we need? Do we need a development firm that's mostly site builders with one or two developers? Or do we need a development heavy team that's going to be writing everything new for us or plugging it together in a different way? Lullabot has a really, really great podcast speaking to this, sort of giving you a little tidbit on what is a Drupal site builder, when are they really valuable, and when do you need a developer brought in? And they're very neutral about it, which is really nice, so you can check that out if you want a little bit of background going in. Last slide, I think I've talked way too fast, but that's fine. The last thing I'll say is, when you're going in for your project and you're starting to talk with different development firms, things that should be a given, or red flags to watch out for, responsive design should be a given, okay? If somebody's like, oh, we can cut down the budget and we'll just do it for desktop, right? It's like, that's a concern, okay? This is everything, it should be mobile-friendly, mobile-first these days. And I see some people smiling, I guess actually came up recently. So responsive design should be a given. AODA compliance, beyond compliance. You need to be working with a firm that has full usability in mind. We were recently at another conference where there was a really great panel where they talked about, yes, you can pass compliance tests, but if you actually have an individual who has a need, have a screen reader or something else, actually use it. Is it user-friendly? Is that an enjoyable experience for that person? So make sure that your firm isn't just shooting for compliance, that they're looking for full usability for any Ontarian or Canadian or whoever needs to access it. Multilingual experience, we're in Canada, okay? The vast majority of you do need bilingual websites and working with people who know how to navigate that more appropriately have a lot of experience in that. Drupal's great at multilingual, but ask them, you know, your websites in your portfolio, are they English, French, or English and any other language that they worked with? Code quality review. Are they looking at their code? Are they making new modules? Are they, you know, doing things on QA and prod, not just doing stuff directly to prod because that's also a concern? Making sure that they care about the code that they're putting together. And do they have a maintenance plan, right? We've had a couple instances of clients who've received websites and then the firm says, bye, have fun. And then we get the website a couple of years later and it's like nothing, no security updates, no nothing. So if you want to build a website or a web application, you need to go in knowing that there's gonna be costs to keep it updated and going and running smoothly. So what are their maintenance packages? What are their maintenance plan going forward for your website? So I think that's it. I probably talked way too fast, but I bribed you with cake, so that's why I'm here. So that's my spiel. Any questions? I'm okay with that. Come up and chat with me, otherwise, go hang out. Go have some water, there's no food. But just go, hang out, have a good time. Bye, guys.