 This is a business track session. This is a non-code presentation, so if you're looking for Drushmake files or crazy things like that, this is probably not the place for you. My name is George Domet. I'm the founder and CEO of Palantir.net. We're a Drupal web development shop based in Chicago. I was also co-chair of DrupalCon Chicago, a member of the Drupal Association, and you might remember me from Dries' keynote this morning. They seem to have slipped in a picture of me on the workbench slides. So I'm here today to kind of talk about the process of building websites, of doing web projects. So this is really a good session, hopefully for folks who are either considering, you know, using Drupal for a project within their company or organization, somebody who might be partnering with a firm to do a Drupal development project, or maybe you are a Drupal developer, a freelancer, work with a company, and you're really just trying to kind of understand what some of the best practices around approaching a project, staying on track, on budget, and ultimately delivering sites that meet client expectations and that everyone can be proud of. So I want to start actually by talking about managing audience expectations. And this is a poster for The Tree of Life. This was a movie, I don't know when it came out over here in the UK, but it came out earlier in the year in the United States. This is a film by director Terrence Malick, who makes about one film every 15 years. And they're always very highly critically acclaimed films. And, you know, he gets pretty well-known actors to appear in them, just beautifully shot works of art. But they've never really done huge box office business. And this is his most recent film, Tree of Life, with Brad Pitt and Sean Penn. And it tells a story of a family growing up in Texas in the 1950s. It tells the story of one of the children from that family 50 years later. And it also tells the story of the creation of the universe. And these three narratives are strung together in not really a way that would make sense to a lot of folks. You know, you'll be watching them watching the film. And I'm not really spoiling anything here, but you're watching the film and you're getting engrossed in the story of this family of Texas. And all of a sudden we have a scene about dinosaurs. And so this is this is an example of a classic art house film. And it doesn't really adhere to a lot of the the rules that we've come to expect for Hollywood screenwriting. And so as a result, while critical reception of this film has been really, really positive, for audiences have been widely split. So for example, one theater, in fact, had to go to the lengths of putting up a disclaimer outside the door to the theater where this film was showing. And I'm going to read this here because it's it's not very clear on the screen, but it says dear patrons, in response to some customer feedback and a polarized audience response from last weekend, we would like to take the opportunity to remind patrons that the Tree of Life is a uniquely visionary and deeply philosophical film from a not your director. It does not follow a traditional linear narrative approach to storytelling. We encourage patrons to read up on the film before choosing to see it. And for those electing to attend, please go in with an open mind and know that the Avon has a no refund policy once you have purchased a ticket to see one of our films. Avon stands behind this ambitious work of art and other challenging films which define us as a true art house cinema. And we hope you will expand your horizons with us. Thank you. So I love this disclaimer, one, because it's kind of condescending as all hell. But it really does, I think, bring home the point that I think a lot of us consider ourselves very, very creative folks. And there's a often a desire to really push the envelope, break the rules and do something different. And I think that's absolutely wonderful. And I think folks should do that. But what you're thinking in terms of a client project, a project where you're getting paid tens of thousands or hundreds of thousands of dollars to build a site for somebody, you really want to make sure that they know what you what to expect going into the process and that they know what they're going to get when they at the end of it. Because if it's not what they expect, they're going to be pretty unhappy. Which leads into my point about the cost of failure. And this is a movie Cutthroat Island. Has anyone in this room actually seen the movie Cutthroat Island? Couple folks? Did anyone see Cutthroat Island in the movie theater when it came out? That's what I thought. So this movie came from Carl Co Pictures, which was known for doing Terminator 2. I think they did the first two Rambo movies. They had done some some pretty big films. And, you know, big box office successes. So they they they did this film Cutthroat Island cost $115 million back in 1995, which was a big chunk of change for a movie budget those days. It's still pretty big chunk of change for a movie budget. But it was a lot back then. And it had a box office of only $10 million. So they lost over $100 million on this movie. And I it was just incredibly unpopular. No one went to see it. And it was kind of a mess of a movie. I mean, it's not the worst movie I've ever seen. But it's not great either. It's certainly not something you would expect from that kind of investment and the kind of star power and the kind of, you know, caliber of filmmakers that were behind it. And I think one of the reasons for that is that production on this film was incredibly rushed. And they actually started building sets and shooting scenes before they had finished the script. So they were in this position where they were literally just kind of making it up as they went along. And the result was that it ended up bankrupting Carl Cole pictures. And in a broader context, it also meant that because this was a movie about pirates, no other Hollywood studio wanted to go anywhere near any movie about pirates. In fact, it was eight years later, that Pirates of the Caribbean with Johnny Depp was really the first major pirate movie since this particular debacle. And I think this makes, you know, again, a really good point about going into the process with a plan, knowing what you're doing, particularly if you're dealing with a large project, and making sure that you don't end up with a cutthroat island on your hands. So let's talk a little bit about the Hollywood storytelling formula. You know, those of you who, you know, go to see Hollywood movies, if might have noticed that there's, there's kind of a similar structure to them in terms of the storytelling. In fact, it's a very deliberate structure. This is the basic film, the three act Hollywood structure was really a guy named Sid Field back in the 70s screenwriter, he teaches screenwriting classes. He was the one who really kind of diagram this out. This this structure actually comes from it has its roots in Aristotle, you know, and it's been been carried through the century. Sometimes it's three act structure, sometimes it's a five act structure. But generally, it's the same sort of idea that you have this basic film paradigm. And about 90 to 95% of the scripts that are made in Hollywood adhere to this formula. And in fact, movie producers will often, when they're reviewing a script, what they'll do is they'll actually go through to particular points in the script to see if there is a plot point change. You know, and if it's not there, they will just kind of reject the script if it doesn't meet this formula, because all of the most popular box office films adhere to this. So let me let me explain a little bit further. Let's in the context of the film that hopefully folks are seeing called the matrix. So you start off with the setup. The setup in this case is, we meet Neo played by cannery is ordinary office drone who's a hacker on his off time, gets mixed up with Trinity and the rest of the gang and finds himself on the run from mysterious agents. So there's big plot point number one where where Neo has to make a decision. Does he take the red pill or the blue pill? And he ends up taking taking the pill, the red pill and he sees how deep the rabbit hole goes. During the second act of the film, Neo is introduced to the matrix. He learns about the conflict between man and machines in this virtual world of the matrix. He trains up, he learns kung fu. This is all building, building, building to the third major plot point, which is when cypher betrays Morpheus, who's then taken captive and Neo has to again make a decision. And he makes the decision to try to go and rescue Morpheus. And then the third act is is full of your, your big action set pieces, the big rescue sequence. And it's where Neo kind of realizes his powers and becomes Superman, basically. So it's, it's, this is a film that adheres very closely to the structure. And if you if you go back and you watch movies, you can really kind of fast forward to about 20 minutes into a film, fast forward to about 20 minutes before the end of a film, and you'll see these kind of major plot points. And as I was thinking about this Hollywood structure, I realized that it had some parallels to what we do in the, in the web development cycle. So we start out with the discovering design phase. We have a key deliverable at the end of that phase, you know, a functional specification, a feature list or a feature narrative and design. We have this big middle segment where we're going through the development process. We get to a major point, which is the beta release. That's the feature complete version of the site that we've been building. And then we have this final act that's that's full of all kinds of action and explosions and things going back and forth quality assurance, right, before launch. So let's walk through what that looks like for a single project. This is a project that we did recently for Minnesota Public Radio. This is the MPR archive. So this is essentially a site where you can go and search through almost all of Minnesota Public Radio's archive of recordings and news reports and things like that. You can hear stuff, Hubert Humphrey speeches, you can go back, you can hear recordings from when Garrison Keeler was a morning DJ, all sorts of stuff that would be very familiar to anyone who listens to public radio in America. So this is what the finished site actually looks like. So let's walk through the process of how that was built. So we had Act One, Discovery, Strategy and Design. Key points here. Obviously, listen to the client, involve stakeholders, understand what the business needs of the site are, develop a feature narrative, what are the features that are going to be on the site? What is it going to take to build those features based on the business requirements that you've gathered? Wireframe the site, what is the kind of skeleton of the site going to look like? Create a style guide that really dictates the look and feel of the site and the user interactions. You have some key players during the stage, right? You've got a strategist who's responsible for the gathering the business needs. Tech lead who's kind of the person in charge of the technical team that's going to be responsible for implementing this. That person is also working with a strategist to try to understand how to translate some of these desired features into something that's actually buildable. You have a designer or a user experience person who's helping develop the look and feel. This could be somebody you're collaborating with as well. And you have a project manager whose job it is to kind of coordinate all of these different players and make sure that everyone is on the same page. So the feature narrative which is one of the deliverables of this phase is a narrative document that outlines the site functionality and the technical approach to implementing it in Drupal. It's a big long document. It's got a list of all the features associated with the project, the level of effort associated with each one. And this is really a key decision making tool for clients when they're prioritizing features against budget and timeline. And it's also a really great tool for the developers to really begin to dig in and understand what it is that they're going to be building for this project, not just what it is they're going to be building, but why it is that they're going to be building it. So let's take a look at the the section of the feature narrative for the Minnesota public radio. We're just going to really primarily be looking at the homepage during this. So we talked about level of effort 24 hours to build summary. This is what this thing is going to do important that this be written in plain English that the client can understand details. This is where the functionality is going, what the function the details with functionality is going to be where it's going to appear. We've referenced wireframes and designs will be looking at it a bit. And if there are any other features that are related to it, oftentimes you'll have one feature that interacts with another feature in different way. And we do this for every single feature on the site. And what this does is it enables the client say, Okay, you know, I've got this big huge laundry list of things I want to do with the site. Oftentimes, that laundry list is a lot more than what they have in their budget or timeline. And but by going through and doing this for every single feature, they can take a look and say, Okay, this feature is really, really important. So we're going to prioritize it. We're going to make sure we build it. This other feature nice to have. But really, if I have to spend, you know, an extra X amount of money, and take an extra, you know, X amount of weeks on the project, that can probably wait till phase two. So this is a very useful tool for the client from that respect. The wireframes, the wireframes help a number of folks, they help the designer, who's going to be responsible for the look and feel, understand what the functionality is, it's going to be on the site, how it's going to work. It helps the developer understand the context for this functionality that they've just specced, helps the themeer understand what regions are going to be used on the site before they begin theming. And it's also a useful tool for the client to really understand kind of how are the different pieces going to fit together. So let's take a look. So these are the wireframes for that Minnesota public radio site. You can see we're not doing any branding here, we're not talking about colors, typography, anything like that. This is pretty much, we got a little bit of typography, I guess. But this is really just kind of what's going to be there, where's it going to fit, where are we going to put the advertising, where's the main branding going to be, the links, all of those things. And this really enables the client to really evaluate this without getting distracted with things like, I really don't like this color blue that you're using here. So then once we have that, we can dive into the style guide. This is a key design deliverable. And this is generally an annotated document that describes the layout, the branding, the typography, navigation, there's going to be media and other elements. We talk about all those different things. We talk about each of them distinctively because they will often be reused in different sections of the site. We're working with a content management platform, we're working with Drupal, and we can reuse content, that's one of its strengths. We can reuse pieces of functionality. And we want to make sure that when that piece of content or that piece of functionality is repeated in another part of the site, it's being done in a way that looks and feels like it's part of the site, it's not just bolted on. So let's take a look at the home page. So this is what we've done. This is kind of the full, this is a layout of the home page. We've got the branding in there, we've got the colors, we've got the full typography, we put in some mock ads. This is also in the style guide where we talk about things like spacing, how elements are separated. So I don't know if you can see it, but there's actually, there's a grid here, it's both a vertical grid and a horizontal grid. So we're not just concerned with things like what the page width is, we're also concerned with something we call vertical rhythm. As you scroll down the page, you know, you don't want different elements to be spaced differently from each other. You want everything to look like a designed and consistent experience. Even if you have no idea what content is going to be going in there. So we've got our, we've got our deliverables from Act One. Now we jumped into Act Two, right? Development. Development. This is the kind of main section, this is the biggest part of the project where all the different players are involved in progressively building out the features and functionality of this project. Of course in a version controlled development environment. One really great way to kind of get started is to leverage base installations or distributions and theme frameworks. We use Zen, other folks use other frameworks. But it gives you a baseline to start from. And so you're not reinventing the wheel. We'll talk a little bit more about the elements that make up a good platform in a little bit. But during this phase, you're iterating frequently. You're pushing code to the client staging environment on a predetermined schedule so they can review this. These are regular code drops. If we're talking about films, you can think about it like dailies on a film. They will shoot the scenes for a particular day. They'll go back and print them. They'll review them in the in this studio that evening as they're preparing for the next day's shoot. And they'll say, yeah, did this turn out okay? Do we need to maybe tweak some things? And they'll be able to make those kinds of decisions on the fly. You have daily project scrums with the team. Very brief short meetings where you kind of touch base on the status of the project. This meeting should not take more than 15 minutes. If you ever hear somebody say, I just came out of a 45 minute scrum, that wasn't a scrum. That was a meeting. And you want to report back to the client with at least weekly status reports. You know, generally most clients, particularly on larger projects, want to know what the burn rate is. How are we doing? How are we tracking against time? How are we tracking against budget? And the key players you have at this stage are the tech lead. Front-end developers who are who are kind of new players in this phase. Project manager who's the same project manager that we've had throughout. And of course the strategists and designers who are still involved, who are still available to answer questions and to validate assumptions and to make sure that we're proceeding on the right track. So I don't have any pictures of anyone like doing code. I think we kind of all know what that looks like. But I did want to show, picture, this is a project plan. This is something you should have before going into this phase. So we've got this divided out into the different weeks of the project. This is a 10-week project. We've got the different players here. We've got design. We've got some, we've got developers and we've got different component developers for different aspects of the project. Themers, quality assurance, both on the developer side and on the client side, who are going to be involved. Bug fix, documentation, training, the whole thing. And this is kind of the master plan for the development process. And then here's a sample burn report. So you can see, you know, we've got so many hours allocated for this project. Here's how many hours we've been spending on it during each of these time periods. In this case we're tracking by month. So we've got a budget of 854 hours. We've used 637. We've got 217 left. We think we're going to need about 153 hours, which means that at this point in the project it looks like we're coming in about 63 and a half hours under budget, which is great. And what this means is the client has a good sense of this project is on track, on schedule. You know, there's no promise that we're actually going to come in at the end. We might run into some issue in QA or toward the end of the development process that might eat up some of those extra hours. If we don't, that's great as well. You know, we're also tracking against the different roles in the project as well. So, you know, we can see how many hours we're spending on project planning and management, how many hours we're spending on design, how many hours we're spending on development in QA. And we have different buckets that have been authorized for each of those line items. And you can actually see we're actually, in some cases, you know, in this particular project, we actually went 23 and a half hours over on design. Fortunately, we've been coming in under on some of these other buckets. You know, plus we have a contingency bucket, which is kind of the bucket for things we didn't expect. And that's something that's really useful to have in a project and to make sure you're very transparent about that. Because no project actually goes exactly as planned. So then we jump into Act 3. After we're done with this development phase, we've been progressively building stuff out, we get to a beta. Beta is a feature complete version of the site. It's not launched yet. It's still living in the client's staging environment. But this is the point where we're going to kind of go back and validate and check and make sure everything is working the way it's supposed to work. So this is the good place where we're populating content. Having clients populating content on a beta site is a really great way for them to do some quality assurance testing, to get used to the site. If they're having trouble understanding how something works, this is a really good opportunity to answer those questions. And you're continuing to refine the front and back end based on feedback. You're validating that the site meets your design, functionality, and business goals. Providing the client with orientation, training, and documentation. And at some point when everything is happy, you're going to move from, if you've been working out of a development environment, you're going to move the authoritative version of the site to a staging environment. And then after we've fully completed this QA process and everyone signed off and everyone's ready for launch, that's when you're going to either launch the site from the staging environment or move it to a final production server. Key personnel, this looks pretty familiar at this point. Tech lead, strategist, designer, project manager. You know, important to bring back your strategist and designer and really make sure, because they're the folks who've been most involved at the beginning in Act 1, and have them come back and take a look and say, hey, you know, are we hitting our marks here? Is this site actually doing what we intended it to do, which is a question that I find actually doesn't get asked often enough. But it's kind of an important one. So for quality assurance tickets, we use software called RedMind. Other folks use other programs. We've tried a bunch of them. The one that works best for us is RedMind. And here's a sample QA ticket. This should be a familiar kind of quality assurance issue, hopefully to most folks. Search text is not vertically centered in Internet Explorer. What a surprise. So what this does is, actually, our strategist was the one who filed this ticket. He was going through and looking at the site and doing some validations. He noticed this issue. You know, properly speaking, it's actually a design issue, but anyone can file a ticket if they notice something is out of whack. So this was signed to one of the front-end developers. We had, you know, an estimate that this would take about an hour to fix. It took about an hour to fix. We talked about the page. This was a home page issue. The URL in our QA environment where we were seeing it. There was actually a screenshot attached and a description of the issue and the browsers in which it appeared. And so he had a really good understanding of what this issue was and was able to fix it. And so, of course, let's go back. This is, you know, what the final version of the site looked like. This is the live version of the site that I took a screenshot from yesterday. So this is the basic process, right? And it was hopefully kind of familiar. And it's awesome, right? Except for one small issue, which is that life is actually a lot more complicated and projects are often a lot more complicated and messy. And a really great analogy I found for this is something called the sleeper curve. A guy named Steven Johnson wrote a book a few years back called Everything Bad is Good for You. And the premise of this book is that movies and TV and video games and all these things actually help make people smarter. And one of the examples he used for this and talking about how popular culture has gotten more complicated and more interesting over time is if you take a look at the number of plot lines in a show like Starsky and Hutch, for example. Starsky and Hutch has basically one main plot line with a little comedic subplot that pops up at the beginning and the end. But otherwise it's a very self-contained thing. We stick with the same characters throughout. There is one main story, very digestible. In the 80s you have Hill Street Blues come along. Hill Street Blues has a whole bunch of characters all over the place who are involved in doing all sorts of different things. And they have often overlapping interactions with each other. And there's multiple threads and plot lines and things going on at once. When this happened, it came out in the 1980s, the television producers were scared out of their minds that people would be confused and not understand this program. But they did and it was a huge success. And it showed that audiences had the capacity to process more than just a single plot line at once. And then in the 90s we move on to the Sopranos. The Sopranos looks a lot like Hill Street Blues. If you take any given episode, right, you've got all sorts of different characters which you actually see here in a general episode of the Sopranos is actually not only do you have the same number of plot lines going on, but instead of them being all split up, they're actually overlapping each other. So you have multiple overlapping interacting plot threads. And what this doesn't show is that you actually have this going on not just within a single standalone episode, but you have plot arcs that are extending over an entire season or even in some cases multiple seasons of the television program. So it's a lot more complicated. And as I was thinking about this, it reminded me of the development process. And the point here is that when you're working on a large complicated web project, you often have multiple tracks running simultaneously with different players on different parts of the project. It's not just a single person running throughout the entire process. It's a whole team with developers, designers, strategists, QA people who are coming in and out of the project and have roles of varying sizes at different points in the project. So it's gotten a lot more complicated. It's not just a single three-act structure anymore. So it brings me to the idea of non-submersible units. What are non-submersible units? It's a storytelling technique that you see in some films. The person kind of most responsible for pioneering it is director Stanley Kubrick who did 2001, Clockwork Orange, The Shining, lots of kind of well-known kind of cult films. It's also used by Russian filmmaker, was used by Russian filmmaker Andrei Tarkovsky and also Quentin Tarantino uses it quite effectively in films like Pulp Fiction and Kill Bill. The idea is that you take the narrative and you split it down into six to eight independent essential story parts. And you could actually take each one of these story parts, these non-submersible units, and you could actually watch it as a standalone vignette. It tells a little story inside itself. But when you string it together in a logical order with other story parts, it makes up a larger narrative and the audience is trusted to be able to make the connections between them. So to illustrate this, let's take a look at the film 2001 Space Odyssey. And in 2001, I've identified half a dozen non-submersible units here. These are the ones I think exist. Other folks believe that there's a different set of units, but these are the ones I like. And 2001 Space Odyssey is basically boiled down into these parts. You have the very first part of the film, The Dawn of Man, which is about these prehistoric proto-human ape creatures who are struggling to survive. They're visited by a monolith from outer space, which basically helps prompt them to reach the next step in their evolution. They learn how to make tools. When they learn how to make tools, then they're able to prevail and survive and thrive. We then jump cut from these scenes that are taking place four million years ago in the African savannah to the near future, where we see spaceships and space stations and a journey to the moon with a space bureaucrat who's going to the moon and he ends up because it turns out that he's discovered a monolith on the far side of the moon. When the monolith on the far side of the moon is exposed to the sun for the first time, it emits this loud piercing signal that's beamed out into space. We then jump again a few months later to the spaceship Discovery, which is on journey to the planet Jupiter. And on board that spaceship, we've got several human crew members, Frank and Dave, our kind of man in the ship. We've got a few more crew members in stasis, and we have a crew member who is an artificial intelligence computer, the Hal 9000. And so we kind of get to know those folks. Well, we then have an issue because Hal makes a mistake and Hal's not supposed to make mistakes. And so Frank and Dave kind of get together in a pod. They think they're out of hearing, and they plot to disconnect Hal because if he's making mistakes, he's not reliable. They can't trust him to run the ship. Well, it turns out Hal observes that conversation, understands what they're saying, and basically goes berserk. And so he decides to kill them, basically. And so then the rest of that story is about them as about one of the crew members basically overcoming this threat from the Hal 9000 and prevailing over him. We didn't arrive at Jupiter where it turns out that there is another monolith in orbit around the moons of Jupiter. And Dave, our protagonist, gets into a pod and he's transported across space and time into a mysterious visual special effects place for lack of a better term. And when he arrives at the end of his journey, it's in a very strange kind of cold looking hotel room where he is mysteriously transformed into a star child. So each of these things, you can watch kind of each one of these vignettes on their own, but they also make up a single narrative. And it's a narrative that is patched together. And audiences are trusted to make the connections. They're trusted to make the leap from four million years ago to the near future. This was actually something a lot of audiences and critics had a problem with. They had difficulty with when the movie came out in 1968. And when 2001 came out, it's universally regarded by critics as kind of a masterpiece today. When it came out, critical opinion was really, really split on this film. Some people understand it. It's a total junk. But then they went back and watched it again. And a lot of these critics actually changed their reviews and recanted. They went back and they went, they're like, the first time I saw this, I didn't get it. I thought it was crap. And then I watched it again and I get it now. I understand what's going on here. And this is actually a really great, innovative film. And I think this non-submersible unit structure is actually really similar to a good agile process. I think there's a lot of misunderstanding of what agile means. I've seen agile processes where essentially it's treated as let's gather a whole bunch of requirements together and let's just kind of build them out until the client runs out of time or money or whatever. And whatever we have at the end of that, that's what they get. I don't think that's a really great way to manage expectations or help the client achieve their business goals. To me, what agile means is about collaboration and it's about breaking tasks down into small chunks, small standalone chunks that can be worked on in a logical order. You release the features progressively in cycles. So we are continuing with this idea of we're building on what we have built before. But the work is done by very small, very focused, very collaborative teams, very small little chunks. And so to me, that's how you kind of tackle this problem of how do we deal with the really, really complicated projects where you have these multiple narrative threads going on. You break them down. You treat them as separate units and you deal with them in a logical order and you tie them together into the main project as a whole. So let's change gears a little bit. Let's go through every James Bond movie in 30 seconds. Are we ready? All right. So we have the opening pre-credits sequence where James Bond is in some kind of action sequence. We then jump into the opening credits, which usually have these kind of animated backgrounds going on that usually feature guns or girls and guns. We start the main movie. Bond gets a mission from M. He flirts with Miss Moneypenny. He picks up some gadgets from Q or R. He travels to an exotic remote locale. He meets up with a friendly foreign agent, who's often named Felix Slider. There's a chase sequence. He ends up meeting a bad guy who's got a plot, who's tending to take over the world. Bond ends up defeating the villain, blowing up his lair, and then he makes love to the girl. The end. That is every single James Bond movie. There have been, I think, what, 20 or 22 Bond movies made in the last 50 years and almost all of them exactly follow this plot. And they've made something like $12 billion at the box office. So why do we keep going back and watching this same damn movie over and over again? Why does this work? For a few reasons. One, you can add new characters and settings and situations into the formulas. It's a little bit different each time. The movies evolve over time to mirror real-life events in our own world. So back in the 60s and 70s, Bond was fighting against the Soviet Union and communism and specter and all those things today. He might be dealing with, in the 90s, he was dealing with media tycoons and the North Koreans and other threats of the time. It changes over time, given the realities of the world we live in. It's a mirror. The formula isn't necessarily set in stone. It can still deliver some twists and turns. So I said at the end, he makes love to the girl. Sometimes the girl dies. That's happened a couple times. But ultimately, the Bond franchise delivers an experience that meets audience expectations. When you go to see a Bond movie at the movie theater, you know what you're going to get. You generally know what kind of movie it's going to be. You don't go in expecting a romantic comedy. You go in expecting this kind of movie, action sequences and intrigue and exotic locations and all of those elements. That occurred to me. This is very similar to the elements of the successful Drupal platform. Drupal itself is a platform. But a lot of folks, as I said before, when you build a, you start off with not just core Drupal that you download from Drupal.org, but you start off with a configured version that's got your most common modules and features and different things already kind of set up and pre-configured. That might be a distribution that you get from somewhere. That might be an installation profile. That might be something that you create yourself. It doesn't matter. The point is, though, if it's going to be successful, it should be customizable to meet specific use cases. You could have a Drupal platform that meets 80% of the needs of a given audience use case. But there's always going to be a certain percentage that's going to need to be customized to meet very specific and custom business needs. You can add to and extend it over time. That's Drupal. It's this very modular platform. We can download new things. We can update modules. We can update it. We can add it. We can expand it. If new web technologies come out, they can be fit in. You can use it in non-obvious ways. Out of the box, Drupal is this kind of website publishing platform. But you can use Drupal for all sorts of crazy, weird, odd things. And it's one of the reasons actually I like working with Drupal is that we do a lot of sort of weird things, where we're being asked to integrate all sorts of different third party systems for colleges or digital asset management systems for museums or media organizations. And Drupal is that kind of like magic glue that you can use to bring together all of these diverse systems into a single unified interface. And it delivers a consistent experience that meets users' expectations. So when you log into, when you're responsible for administering your Drupal site, it should look and feel a particular way. And it should enable you to update your site and to accomplish the tasks that you're trying to accomplish. So that's what I have. Thank you very much. And I have left some time for questions. I don't know if there are any mics out in the room or not. But if not, I guess, raise your hand, and I will call on you. Yes? I'm sorry to be loud. OK. So that's a good question. The question is, what's the difference between the Drupal development process and the general web development process? I think it's similar in a lot of ways. We were working with other platforms and kind of making our own for about 10 years before we started working with Drupal. And I would say, in general, that kind of 3x structure that we talked about earlier in the process, with some tweaks and changes, that's a very generalized structure for web development in almost any different platform. What Drupal enables us that's a little bit different is the ability to kind of start out with that base to really, it is a platform that I think fosters agile development to a certain point. You're not reinventing the wheel. You're not building new things from scratch as often. You might be, if you've got a project that calls for, hey, this project needs a new module for X or Y or Z or whatever. But in general, you can kind of leverage work that's come before. You can take existing modules. You can integrate them. One of the reasons that we like it a lot is obviously the strong community support and the ability to integrate with other third party systems. So when you're working in general web development, you might either be working with a platform that has that kind of support or you might be in a position where you're building it entirely from scratch. At that point, if you're going to try to do agile development, you have to have a really, really strong process built around it because otherwise it's just going to kind of spiral out. Drupal has really great standards for the way that thing should be built. And best practices. And if you follow those, you're going to end up with a really robust product. I think that's not going to break if something needs to change six months down the road. Yes, right. So the question is, how do we take customers who might not be used to an agile process? How do we manage their expectations and get them involved and understanding what the process is? For us, it is about talking about it a lot up front and kind of helping them understand what the roadmap for the project is going to be. It's also about as much transparency as possible. And that one is you have to be a little bit careful with that one just because too much information can kind of overwhelm the customer sometime. And when you're working in an agile process, that's a real danger. What we usually do is we try to, in the beginning part, in that first act in the discovery process, try to understand what the customer's level of comfort is. Some customers are going to want to see like, we have customers who want daily code drops. And they've got teams on their end that are very involved in the development process and are up to speed on it. We have other customers who are just kind of like, here's what I want. Come back to me when it's done. Usually we try to hit somewhere in the middle so they can see work in progress. I think having those regular status calls with the client saying, OK, here's where we're at. Here's what we're building right now. Here's what we have built. Here's what we're going to be building next. That's really helpful and useful. And it helps the customer kind of understand what the trajectory of the project is going to be. I don't think you need to get into kind of a whole discussion of like the philosophy behind Agile and comparisons to Waterfall and all these. You don't want to get too technical. You just really want to say, hey, here's how we're going to build this for you. Here's how we're going to maximize our efforts to enable you to get the most bang for the buck or to allow you to launch your site by this particular drop-dead date. And we're going to continue to have conversations about it throughout the process. And if you have questions, ask them. And we have clients who come to us in the process and say, I don't really understand what's going on here. Can you help me? And so we do that. And you say, OK, no, we got a call. Let's refresh you again on what the process is and make sure that we're all on the same page. But yeah, that's all about lots of good, consistent dialogue and communication. And that's where having somebody who is kind of a direct customer contact, project manager, as usually that person, a strategist or a technical lead can also be that person, depending on the kind of questions that are being asked. So that they know, you know, that they have a person that they can talk to, that there are people running the ship, as it were. Yes? Yeah? So, you know, I didn't want to get into too much detail about the tools because everybody's got a different set of tools that they're comfortable with. And depending on the scope of the project that you're working on in the makeup of the team that you have, a different set of tools is going to be what you're most comfortable with. I mean, my personal philosophy is use what you're comfortable with. I can tell you the tools that we work with for generating those burn reports. Those, yeah, those are spreadsheets. The information for them comes out of the red mine ticketing system that we have for each ticket, which is integrated with Toggle, which is an online time tracking tool. So we built a bridge between those two systems. And that allows us to do really great reports that tie time spent on a project to a specific ticket or deliverable. In terms of wireframing, I'm not sure what we're using for wireframing right now. I know that we have used. We're using Omnigraphl right now. Thanks, Tiffany. Tiffany is a co-owner of Palantir. So, yeah, Omnigraphl, I think we've even used, I think we've even used image-ready sometimes. I know folks use that. Illustrator, but that's an awful lot of overhead if you're just trying to do simple wireframes. I've seen wireframes that folks do that are just kind of literally paper sketches. But with our process, we like something digital. And I think there was a question right behind. Yes? Well, so for the discovery process, you mean, yes, yeah. So I think that's becoming a more accepted practice. It was definitely something that was a lot more difficult to explain to clients or perspective clients a couple of years ago say, okay, so you're gonna hire us and we're gonna spend this big chunk of hours planning. And at the end, you're going to get basically, and the way I would describe it is, you're basically gonna kind of get a set of blueprints, right? So if you wanna build a building, you don't have the builders start building without an architect drawing up a set of blueprints first. And that's a service that you pay for, right? That's distinct from the process of physically building your building. But I think that increasingly, clients are understanding, particularly as the projects get larger in scale, understanding that we need to set aside some time to have professionals come in and do the business analysis, do the technical analysis and deliver that first. And what we actually sometimes do is we will include along with the discovering strategy, design will also be part of that initial engagement so that at the end of the process, the client will not just get a sheet of paper or it's a rather large, thick volume with a whole bunch of stuff written on it. They will also get some design concepts that they can take back and show. And that's really useful, I think, if you're dealing with organizations that have stakeholders who are not as involved in the process, that they're executives or board members or whatever who hire, they're like, oh, we've hired a firm, right? And so then they can see at the end of the process, oh, this is what our new site is going to look like. And so that is a helpful deliverable for those folks as well. But I've seen that be less and less of an issue. I think that folks are really kind of coming to understand that, especially if they come in like, well, we have this idea for this thing and we wanna do this and that, but we don't really know how it would work. Can you help us out? They're more often willing to pay for that consulting and strategy. So the question is about, do we basically provide the full proposal? Usually what we do is we will provide, yeah, because they'll issue an RFP for the whole project. What we will do is provide, we'll go through and we'll talk about our entire process throughout. We'll talk about what we think, what we're hearing from the RFP that the site needs, where the project needs, and what features we can have experience developing and everything. We will provide kind of a fixed bid for the engagement process or estimate for the engagement process. Then we will also often go in and say, if we can, we will go in and say, and we're looking at overall what you've asked for and here's a ballpark range for what we think the entire project might be. One thing that we find is that as you get into that early part of the engagement process and sometimes even in the contracting process, we find that the clients will say, well, this is our budget. This is what we have allocated for this project. And if you know what that budget is, then you can craft a solution around that that enables them to achieve their primary business objectives even if they don't immediately get everything in that big laundry list. So that's just a process of helping the client understand what your process is, understand what your capabilities are, and helping them understand that you understand what it is that they're trying to achieve. Now, in the middle back there, middle right there, yes. So that's a really interesting question. The question is about would you skip wire framing and go right into prototyping? I think that that's a question, that's a very valid question. I think that's a question that's gonna come up more often as we start moving into very responsive websites. The kind of sites that actually John Elbin is talking about right now where you have a single site that is responsive, the layout and the design changes depending on the device that you're looking at, the capabilities of the device that you're looking at. So we had a project recently where we actually did do that, where we kind of skipped, well, we had some initial wire frame concepts, but then we really did just kind of jump into the HTML prototypes, and it worked. It was, we found a lot more time consuming, but what it did enable us to do is have a very responsive site design that we would not have been really easily able to achieve if we were trying to do half a dozen different versions of a wire frame for the same page based on whether I'm looking at it on an iPhone or whether I'm looking at it on an enormous monitor. So I think that is a question that's going to depend on the kind of project that you're working on. I think it's going to depend on what the needs of the projects are. In general, I would still say the vast majority of projects, wire framing is the best standard, but there are definitely situations where that might not be true. Sure, it was reusable, most of it was reusable in our case because the person developing the prototypes was an experienced Drupal femur who was very fully intending to reuse that markup in the Drupal site. If it had been somebody who was not familiar with Drupal theming, somebody who was just mocking up a HTML prototype and Dreamweaver or BBEdit or whatever, it would not have been reusable. So fortunately, in that case it was because we had somebody who was really experienced with Drupal theming creating those prototypes. But it very easily, and not all of it was, I mean most of it was, there were some technical decisions that we made during the implementation process that meant that we couldn't use all of it, but we were able to use the vast majority of the CSS at least, so. And I think, am I out of time? One more question, okay, right there. I believe that all the presentations will be available on video, will be available downloadable versions of the slides, that's part of the plan. I know that I've already had to provide an early draft version of my slides, so I think you'll see a final version on the site hopefully within days. So thank you very much everyone, don't forget to fill out the feedback survey. I can tell you, both as a speaker and as a former DrupalCon organizer, having really great feedback and evaluations for every session is super, super valuable when trying to plan programming for future DrupalCons, so please go to the website and fill us out. Thanks a lot.