 Hey everybody. Still a few minutes early, but I thought something that would be cool to do is see if maybe this session could have the most feedback on it. So, does everybody have a computer? Some pen and paper. That's cool. So if you go to this URL and there's a button there for submit feedback, one cool thing you could do is you could hit that button and you could fill it out already to start with what your expectations are. And then in the bottom of it, in the comments, you could kind of, you could write what you're hoping to get out of this session and then any time that you think of something during the session you could keep a note in there and then when the session is over, all you have to do is hit submit. Right? So like preload that feedback, get that ready. Because I would really value that as a speaker and it would be really cool to be the session that got the most feedback. So I'm hoping to get one piece of feedback for everybody in this audience. That's on cool? Yeah. Wouldn't they think it was weird? Because most sessions might get like four or five pieces of feedback and if we had like 20 or something, that'd be cool. So that's a URL of this talk. Is the button on it, button for feedback? You guys are just nodding. I'm just talking and you guys are nodding. There's no button up by the title, the top of the paragraph, nothing to provide feedback? Oh my goodness. This is, well now we've got different feedback to give. Now I don't know what to tell you to do that. I thought that was a really good idea. You have to be logged in. Oh, but someone has the button? Oh, beautiful. All right. Some people have it. All right, super theme. I'm going to get started here. It's a 25 minute session. Talk is usually longer, so I'm going to cruise through it faster. I'm Kelly Albrecht. I'm with Last Call Media. I've been doing a lot of agile coaching, kind of product owner role, business consulting there. And the title of this talk is getting closer to your customer using Drupal in the last mile. So first I want you to think about how close are you now to your customers? Half a mile, some people are maybe a quarter mile. Some people's customers are right here. I mean like, how many customer service people? Anybody doing kind of a customer service role? Or anybody in like a marketing role? Or on a product team? How many people are doing the deployments? Or are you a developer doing the development? You're making the thing that goes into operation. You're developing the product that then gets later operated. If you're in a small business, you can get pretty close, pretty easily to your customer. And that can be a really cool thing. You do a good job, you get that feedback, you get that customer satisfaction. But how are we going to get closer to our customers at scale if we have hundreds of customers or thousands of customers? How do we retain that same level of communication and that same relationship? One of the ways that people are looking at this is by using a mindset called DevOps. There are a lot of misconceptions about DevOps. I think some people think DevOps is just stuff with the servers. A lot of people that maybe have had a little bit more experience think of automation when they think of DevOps. So DevOps is this idea that starts with the development team and the operations team in an organization seems to have this wall of confusion between them. And the development team would develop the product and then they would throw their product over the wall to the operations team who would then reconfigure the work, re-script some of the deployment, and then they would deploy it into their own precious production zone of operation. And as organizations, companies scaled and their customer bases scaled and what was in operation became huge, this model became ridiculous. It became a source of miscommunication, rework, finger pointing, blaming, and there was a big surge in the industry to think about how do we get these two teams to work more closely together? How do we break down this wall of confusion? How do we break down this barrier between the dev and the ops team? And a lot of work has been going into that. A lot of people think of DevOps now as frequent rapid release cycles, as automated deployment with automated rollback, as continuous integration with automated testing, basically automating everywhere where possible to work together and get this value deployed easier, more frequently with fewer miscommunications and fewer things gone wrong. In addition to that, you might think of the feedback mechanisms being also automated, pinging servers or the like, much more complicated to detect errors before the customer can see them and fix it before the customer experiences it. This has been up until very recently, this is kind of a trending topic right now to think about, well, if we can just automate everything, maybe we can just automate the operations team and we'll never have to talk to them again. We can just automate the deployment, so there's, you know, you can go to Twitter, hashtag no ops, people are posting about this idea. There was a paper written back in 2009 saying that we can just automate this whole thing and just deploy things right to operation without any other team. Automate everything where possible. This particular slide is not useful to this talk because we're going to go a little further than this and I'm going to say, submit to you that this is a short-sighted misunderstanding of the DevOps mindset. Breaking down the barriers between the DevOps team, the dev team and the ops team was a great starting point, but there is more to it to get value into operation and to the customer than just this little step. You get in an operation and while it's in operation, you have the product team, you might, if it's for a lot of places, might have a community manager or a customer success team and it eventually gets to some customers who receive that value. And my question to no ops is what are we going to do? Automate this whole thing? We're going to automate the product and the community team? Are we going to automate the customers too? I think we're just, I think no ops is just kicking the can down the road a little bit and it's missing the point of a DevOps mindset. I'll point out that, I don't know if people watch everything that Amazon tells them to, but Amazon told me to watch Philip Dick's Electric Dreams a couple months ago and season one episode two had a episode called Auto FAC and the episode is basically about where artificial intelligence and the machines had taken over and they were producing products, producing products, producing products, but then humanity went extinct. So the machines made robot humans to consume the products that it was creating because the products were getting, were piling up otherwise. I don't think that we're going to do that and I don't think that that fits with the DevOps mindset. So a DevOps mindset actually is about having people work together better, developers, testers and operation engineers working together, having a common business oriented goal that covers the whole value chain that a product, for delivery or product and the teams, the team working as one has the authority to make the changes it needs to make to adapt to, to, to deliver a better product. And the feedback mechanisms that are in place are more than just monitoring servers or code quality, they're in place to ensure continuous assessment of that, the fact of whether or not we're delivering the right product and looking for continuous improvement and learning. So we need the, we need the ops people. We need all the people. Maybe things consolidate and things get more efficient, but this is about working together, all of us. So if we accept that we're not going to know ops and we're going to go with, with the, with DevOps and the ideas behind it, how do we think about this arrangement of teams for things like rapid release cycles, for things like working together better and for things like knowing that we're delivering the right product and, and getting ideas on how to improve it. So rather than that, very linear model or concept of teams, we can think of things as more of a circle where we're delivering and we're getting feedback and we're planning based on that feedback how to improve the product and then we're delivering it again. We're working together to do those things. And so operations, when something's in operation, it's when it's deployed, then it is, then we need to find out how is it working, and then we need to plan together and move that, you know, could be issue creation or plan developing it, releasing those, those feature requests essentially, fixing those bugs. If we think about it, all of those characters that were in that original linear model, if we think about them all as one team, we're, we're back to a very useful topic that I'm not sure anybody who's encountered before but Paul Graham, if you search Paul Graham, maker, maker manager schedule, we're really looking at the distinction between a maker and a manager and how those two work together. So check out that. It's a very short essay written back in July 2009. And this is the idea where makers to best develop their products need focus. And the people that are not developing the product can have their focus be on, on the customer essentially letting the customer know what's, what's been delivered to them, letting the customer know how to use it best, getting feedback from the customer on how they're enjoying the product that's been delivered to them, and then bringing that feedback back, prioritizing it based on what they know about the customer back into the build stages of the continuous DevOps model. There are three things necessary to identify a DevOps model and that would be flow, feedback, and learning. So focus and automation helps with flow, right? So if we get our internal processes or maybe our Kanban boards are set up just right or our sprints are running super smooth and we're not interrupting each other with too much work in progress, we're able to focus on good work. And we've got this, we've got terrific automation, which we have there's, there's 10 other DevOps talks here about incredible automation tooling. And we're able to just think of something to do or come up with something to do, do it really quickly, and just get it right out the door. We have that capability, we have that potential. But how do we know that this isn't just a feature fire hose on our customers that don't really know what they're getting. They don't really know how to use it. It's not exactly what they wanted. How do we know? So we need to go further. We need to, we need to have something as part of our way of working that seeks that feedback. And we need to experiment with what we're producing and learn from those experiments to keep trying to get at a better and a better product for continuous improvement. So what about, so what about the feedback and learning parts? What are we doing right now? And what can Drupal do? What can we do with Drupal to focus on feedback and learning with our customers? So imagine a school department and, and their section of the website. What do they probably think about the website? Well, it probably depends. But one common scenario is they're not quite sure how to use it. It's overwhelming. It doesn't always quite do what they think it's going to do. Maybe it's got bugs that they work around, or maybe worse, the last person who knew how to use the website left for another, another job or something. And no one in the department knows how to use the website anymore. These are, these are common scenarios. Maybe they use WordPress at home, and they know it works pretty good. And it works a lot better in their mind than the buggy product that they're having to use at work. Do they feel confident in their, in their product? This surely affects the value output to the broader audience and any number of originally desired outcomes for the organization. So we need to be thinking about our product and our customers experience with the product. We need to thinking about Drupal and the users of Drupal and their experience with the product. And what more can we do? There's a lot more work that we can do. And this is a great, this is, there's great opportunity here. Every time we deliver value with the product, we can inform our users of this product what's new, right? And if we've been in this relationship for a while, this is a showing of a following through of commitments that we listen, that we fix the bugs, we fix these things, or we heard your request for, for these new features, and we're delivering them. We can also build into our systems ways to show our users of the product, our operators of the product, what it is, how do you use it? Is there, is there enough help? Is the back end of Drupal's authoring experience intuitive enough, helpful enough that people feel confident with this as a product that they're going to stay? Do they feel, do the operators of Drupal feel like a priority in the relationship that we're in as developers of Drupal with the users of Drupal? Do they feel like our priority? Are they going to stick around? We need to be asking, how is this going? We can build in ways to everything that we do to seek that feedback. If it's a help page, we can ask, was this help page, was it helpful? If it's not, how could it have been more helpful? We need to be seeking that feedback. And that becomes the source of what we want to do next to continuously improve our product. And we can also interact with our customers to prioritize what's next. So use cases for thinking about Drupal as a product in this way would be authors in large government education or nonprofit organizations, where their CMS of choice is a product that has authors that are in their, or their organization that need to be using it to produce value for greater organizational desired outcomes. So in these cases, Drupal is the product that's in operation. So there's more work to do and great opportunity. And in the next few slides, I'm going to talk a little bit about some ideas of directions. And hopefully, you all could come up with even better ideas. Because the point of this is not to prescribe how should we, what exactly should we do with Drupal and how should we do it to achieve this? This is not a long enough talk for that. Really, let's get thinking about what can we do to do with Drupal to make it a continuously improving product that people want to stick with, that our end users, our operators of the product want to stick with. So first, what's new? Let's think about communicating what's new with our users of our product, of Drupal with each delivery. There are ways that we can do this and streamline this into our workflow. Here's a familiar screen. I just logged in. Why is it still like this? This gets customized, right? And it's nice that Drupal hasn't made too many decisions for us. But I think there could be a reasonable default. One idea is that we just let people know what's new. Welcome, John. Here are the bugs we fixed. Here are the updates that were applied. I don't think it's too far off the mark to include release notes in the bits of work that we do on our custom modules and our featured, you know, for updated feature. It wouldn't be too much work. Either you're a developer and you know that the groundwork is in place for something like this and wouldn't be too hard to do. Or you're not the developer and this might strike you as a good idea to say, hey, I think my Drupal site should do something like this. Or I want a way to tell the authors of my product what new, cool work we're doing. We listened and we fixed it. And then below that at the bottom, maybe we could have something useful like frequently used content, some helpful information. But up above that is an example of maybe something that you might have added to your site that you want your users to know about. And maybe you could have a little link in there to take a tour about this new content type that we added. Does anybody use the tour module for anything? Tour is in Drupal 8 core. It's available. It's worth looking into. There's also a tour user interface module that will help you create tours. Last call media has also done some work that we'll be contributing back soon that that allows you to use tour a little bit more elegantly and in more diverse situations. But one thing out of the box you can do with tour after you create one is you can go to the URL that it's configured for and add question mark tour at the end and that will auto start the tour that you've configured. So you can have links to places on the website that someone would go to use functionality, but you can trigger the tour to start. So anytime you want to link somebody somewhere that you have a tour built to show them what's new on this page, you can build that into the user authoring experience. So in terms of DevOps and what identifies something as DevOps, we're thinking about flow feedback and learning. Tour is built out of YAML files. So that means that you can build it into the flow of the features that you're developing and adding tour tips or adding tours can become part of the acceptance criteria of a new feature that you're developing. So not only are we building this new feature, but hey, we know that this is a new feature that the customers want here and maybe it's not even built yet, but here's what we will want to say to them when it is built. So make sure that before we deploy this that the YAML file gets created or added to this content. And so on deployment, this tour gets updated and so that information can flow. You can automate the flow of that information. You can ask for feedback on tours. Tour tips allow HTML. So you can put an HTML link to a survey that you're asking like was this tour useful, any sort of drupal thing that you can do. You can hook it up there. And we can certainly learn from that. So this is a tour tip that pops up in the center of the page. That's a configuration option. And maybe you said, hey, we just add this new content type. Here's what specifically knew about this content type. Let's take the tour. You get a tip for maybe one of the most important fields. And on this tip, we can just imagine that maybe there's a help page of longer form content to help with this. And we can link out to that. See where it says, read page help. So maybe there's some help on this. Maybe this field is very complex and there's a lot of content strategy behind this field. And we want to give our authors an opportunity to learn a little bit more to become better authors and produce better content. So this will lead into the next thing that we can consider doing with Drupal, which is basically telling our authors what is this product that they're using and how can they best use it. We like providing contextual guides all over. We can put them all over Drupal. Links to our guides and produce help content to make sure that they really know how they're using the product. What a beautiful thing this is, if we can get budget for it and do it. It would be so great. So this is that tip. This is read page help. The author in this example decides I'm going to go for that. Here's a piece of page help for the for the basic page. And you can see it's got the title. Here's the basic page help. A little subtitle, some intro copy, and then below it it's got a description of the of a couple of important fields. So you can take some time. This is obviously a very basic example, but I'm sure many of you have very complicated content types. And this is the help text field that's in all of your Drupal installs anyway. How many people use this? Not many. Some people can provide helpful information. But what if you could provide even more information, longer form help content on each field. Let's see where this goes. It would show up there, but how can we why not get it to show there? But how can we smooth this out, automate this, make this DevOps-y? I will point out that the help text on the fields, fields are that micro feature. They're on the micro feature level and if we can make it part of our build flow to add and update these with this information and deploy it with everything else, then we've really streamlined and automated the updating of our help pages if we can get it to go in there. So let's say that we were to edit this help page. It might look something like this. Where it's got a title. It's hard to see. It's got a subtitle. Right here we could make all of this information pull from its related content type. If we can relate this content to the content type, then Drupal knows what the description of a content type is. It knows what fields it has and it will know what longer form help content that it has. And so we can have these auto-generated help pages. We can also display this content in different ways. This could be a teaser of a help content page coming from the same information where we have a key components field down here. We have an image field maybe of what the page would look like. And then the related content type can drive the other fields. Even the create a basic page button. It knows what content types it is for. Why not provide a button to create it. So let's carry this even further. What could be useful for that teaser view of that help page? Well remember this page. Add content, blah. What about this page? A page that's a view of help page teasers. You're using the power of Drupal. This is a grid view of those help page teasers. You've built this up automatically fed from all of the help text that you're building into your feature development. Just flowing through, staying updated with every new feature, every tweak. If you're keeping your help text updated, all this stuff is staying in sync. And this view is driving this new add content page for a better authoring experience where they feel like they're really being taken care of. So what else? I said these things. You can further, you know it's just content at this point. Now you just put this abstraction layer of content over top of your content types in this example. You could add any sort of feedback mechanism the same way you'd add feedback mechanisms to any node. So what else? Remember this page? Does anybody ever gone here to get help? You click the help button and you get something that looks like this. This is Drupal's current help system. Well if we did go with this idea of having help be content tied to content types or tied to other things, we could create also create other help pages. It's just help content. We could have a help center. We can build out our tours. We can have a collection of tours. We could have recommended help if we have multiple users giving feedback. You know the most popular help could be there. You could be saving help with some sort of bookmarking functionality that Drupal has functionality for. You could just add a block here if you wanted your authors to be able to contact you for support. Since it's just content, you could organize it by topic and add additional help pages. You could really just help your users and get feedback from them along the way. So you want to make sure to gather feedback on the usefulness of our guidance. We want to know was it helpful. We want it to improve. So we have that there's endless numbers of options in Drupal to do that. I would say experiment with that. And we would use that to collect feature requests and bug reports. And this becomes the what's next that we're going to do with our product. And all of this is to build a culture of closeness and open collaboration between the developers of a product and the operators of a product. Developing software product is complex yet flexible. This means the closer the operators are to the developers, the shorter the feedback loops can be and the better the product will become. Or set a shorter way. When change is easy, awareness fuels improvement. A product is a relationship. Anyone who's been in a good relationship for a while knows it needs to be a priority. We need to be continuously listening and improving. When the relationship is a product, we need everyone's perspective to make our product as intuitive as possible. And the operators of our product are using it every day. The customers are experiencing it every day. What a better source of feedback and information to improve our product with. So if you make a product and you're feeling distant from your customers, get closer. Do this. Start your courageous journey of openness and collaboration to share in a focus on your commitments to continuously improve your product. If you do this, your customers will get closer to you. Thank you. I don't know when the next session starts. Does anybody know when the next session starts? Two minutes for questions. Yes, there's a microphone too. So I haven't got chance to work with the tool module. I have a quick question. Is this module has an API or something which we can integrate with custom content entities? You would, the way that it works right now is you build a YAML file that has a tour that you're defining and a location in Drupal where it's supposed to show up. And then you also define each tip in the YAML file and you target like a CSS class or an ID and you put them in order in the file. And when the tour is triggered, it just shows each tip pointing at the CSS, the target and it just shows the HTML inside the tip. That's it. Okay, sounds like then I have to try that. Yeah, check it out. All right, thanks.