 All right, I'm going to go ahead and get started. It's five o'clock. So hi, I'm Tom. I'm the senior technology consultant at Meadowtoad up in Portland, Oregon. I've worked with Drupal for the past four years, though I've been building websites one form or another since the mid to late 90s. These days, though, I do have to admit I do a lot more consulting and what I would call proxy product-owning than I do coding. But because of that new role that I'm in, I get to spend a lot of time with our clients. I get to form a lot of empathy for the folks that are actually going to use the solutions that we're building. So how many of you out there, at some point in your life, some point in your career, had a job where you had to enter content into a system? And how about a little bit less savory of a role? How about a title of, oh, let's just say data entry? And how many of you folks ever had that sinking feeling at the bottom of your gut that, man, I think I can build something better than this program that I'm being forced to use right now? I know I certainly did. I had that feeling. And years ago, I acted on it. Next thing I knew, I woke up in Portland. I was a developer. At some point, I had two kids, and we got a pug. Yeah, and that's pretty much rock bottom. But anyway, this talk I want to give you today, it's kind of zoomed out. It's very abstract. It's really applicable to D7 or D8. And if we're really honest, a lot of these concepts are applicable to any CMS or any framework. It's really more about taking an abstract approach to the admin experience and thinking of it from the user's perspective. It's building something that's somewhat custom tailored to the people that are going to actually use it. Now, before we begin, I want to share a case study with you of what not to do that I did. Not just because it highlights a time that I horribly fumbled the ball, but because this story is largely what inspired me to do this talk. So back when I was first learning Drupal, I just started learning Drupal when I went to Meadow Toad about four years ago. And a friend of mine was starting a small fudge company. They were gonna sell fudge. And I was more than happy to help this friend of mine set up a website. Drupal in hand, I managed to crank out a fully functional site in about two hours, even being relatively new to Drupal. Now, don't judge me. My design skills are pretty rusty at this point. It's been many years since I was into that realm, but I was just very excited at how easy it was to just set up this functional website. Then it came time to show him how to use it. I want to give you a little bit of context. This person, this friend of mine, is someone that I have a tremendous amount of respect for. He's a very sharp person. He even tinkered with doing some web development back in the 90s. This is someone that knew how to go in and do HTML and FTP back in the day. And he even already maintains a website for one of his other businesses. So while not a developer, this person is fairly tech savvy. So we started out with how to add and edit the fudges. This was easy enough. I went in and showed him the content area. Here's how you add content. Here's how you filter down. Here's how you edit. And he was stoked. This is great, is what he said. Then he asked me about making new pages. Well, explaining page manager and panels, that was a little bit of a challenge. I mean, he still thought it was great. He was still kind of following me. You'd see as I start to glaze over a little bit as I got into some of the details, which I probably shouldn't have. And then he asked, what if I want to change all these colors at some point? Well, thanks to the theme I installed, that was a big win. This to him was amazing. It took me a few times showing him where to find it, being off in the settings, but he thought it was so cool he'd be able to change the colors of his site just by going through a color picker. But then he asked, he wanted to add a few things into the footer. Well, unfortunately, the way I set it up, the footer and the header were blocks. So then I had to go over and show him the blocks section a little bit. Except the footer menu was, in fact, an actual menu. So then we had to head over and look at menus. And then he asked, well, what if I want to make some changes to the list of fudges page? Yeah. Well, that was a view. So, you know, I'm just like, hey, you know what? We probably just don't want to get into that today. I mean, I just totally dodged that topic. Then he casually mentions, you know, I'm thinking about changing the slogan. And I actually used the site slogan, so then I had to show him like where that was, which I probably should have just dodged that one too, because it's like way off in left field compared to everything else we were looking at. And then I realized, wait a minute, I totally forgot that, as I'm just sitting there drush commanding, that I turned on the in-place editor. And you know, I probably should have shown him that first because that's another way to edit all the things, a lot of the things I had already shown him on edit, but in a different place. And by this point I look up at my friend and I see the look on his face and I thought, oh my, what have I done? I mean, he's just slowly, slowly sinking into his beer as I show him all of these things. And then it happened. Then he said something that sent a chill down my spine. He said, wouldn't this just have been easier to do it in HTML? The reason I had a chill is because I realized for him, he was right. For him, someone who edited HTML back in the 90s and knew that type of structure for a site this simple, he probably would have had an easier time with that, as opposed to all the information overload that I just gave this gentleman. To this day, almost three years later, he has not updated this site, not even added a new fudge. And for some reason I still haven't made it better for him. So don't be my friend, apparently. So from that moment on, you know, I came to think of Drupal Admin from a slightly different angle, you know. I tried to make sure to give it a little bit more upfront thought and, you know, planning as I go into setting up a site. So lessons learned for fudge. Minimize the number of touch points for the content authors. Make custom views for focused content administration. Use roles and permissions, even if there's only one user. Train gradually and by topic. Don't try to just dump it all on him. And plan as you build. Always think to yourself, how will it sound when I explain this to the user? There's another reason I'm passionate about this topic. And apparently it's the same reason that Dries is very passionate about this topic. I was glad to see how aligned I apparently am with the community in Dries this morning. All of human knowledge needs to continue to getting up to the cloud. And we're at a point now where it's not gonna be just developers doing it. Gone are the days when the internet was just us building it. Call it web 2.0 or open web or whatever the term is these days, it'll change next month. But as the internet evolves, we find ourselves no longer building the internet, as much as we're building the systems and tools that enable non-developers to populate the internet. Beyond just content created by the general public, businesses are waking up to the possibilities that the web and cloud softwares can bring to what the web and online software can bring to their businesses. They have a need for centralized locations to store information and assets. This is a very common topic that comes up when I speak with our clients. They want one place where their employees can follow the standardized workflow around content entry and maybe even extending the core business data. Then they want to open up access to that content to be used by any number of applications that their business may invest in or even outside of their business. Enter the content once in one place by one person. They don't want to train their employees using several different systems or pay them to manually retype things over and over again. So where does Drupal fit? Well, that depends on the situation. Drupal is not likely to be a core piece of a core business system for a large enterprise. For example, you're not likely to see Drupal selected as the stack to manage inventory, supply chain logistics for Nike anytime soon. It's just probably not the right tool for the job. But what about a scenario where you need an extremely flexible content portal that can handle shifting business needs for the next three to five years? I mean, sure, absolutely. You know, what about a situation where you need a complex admin functionality like workflows and user permissions? And sure, you can slap workflow in there, organic groups. You may be saving months of work compared to if you've chosen another framework or solution. With Drupal 8, the community is being extremely proactive in readying Drupal for the CMS focused future. D8 brought services in the core and now as we saw this morning, I mean, it's just continuing with the dedication to serving content to outside systems. While there are plenty of articles out there, talking about why D8 is amazing, I'm sure there's plenty of sessions here today about it. I want to focus on just one fact, that D8 is ready to be more than just a website. And let that just kind of sink in for a moment. You know, D8 is going to be laying the groundwork for Drupal to become an extremely flexible content administration and workflow platform. While other technologies are the vehicle through which people actually consume that content. The Drupal community's foresight here is going to make Drupal an innovative solution well into the future. So that's enough about Drupal. Let's talk about them, the non-developers, the potentially non-tech savvy, the people that this is all about. People. People are why we do what we do. Everything we build is ultimately meant to be used by people, for the most part. Both the public facing front ends and the content creating back ends, all of it meant to be used by these folks and we can't lose sight of that. The second we do, what we start to build, becomes simply functional. Functional rarely equates to inspirational. People want more than functional. People want an experience. People want to be happy. People want to be efficient at what they're doing. People want to derive pleasure from their everyday experiences. People want more and people deserve more. Why do we love to use Drupal at MetalTode? In short, because Drupal empowers people. Your average person with average computing skills means zero programming experience can be placed at the helm of a Fortune 500 company's web property. Our work makes it so that they can do their work. We empower them. If we just wanted to build a website, we could use any number of frameworks out there. I mean, we're coders. We're not afraid to write some code. But we use Drupal because of the freedom that it gives them, our clients and our partners. When thinking about those people using our solutions, always keep in mind that there's a lot of content authors out there where it's their job. They're spending 40 plus, who knows, it's America, maybe 50, 60 hours a week, creating content for the systems that we build. They just want to do their jobs as painlessly and efficiently as possible. How will they know if the solution we build is not efficient? Because they use it most of their waking hours. People have preferences. Because they're gonna spend so much time using these things that we've built, they're gonna have some opinions. And rightfully so. Some people like things like the in-place editor. They like to be able to click around, browse and edit. Other people would much rather have data in a tabular format. If you haven't ever, check out PipelineDeals.com. I think you can do a demo on there. It can give you some great inspiration. Any user can go in, you can have your own preferences, filters, your own control over columns. Just the overall control of a highly scrubbable in-line experience. My emphasis is on scrubbable. By quickly scanning a list, admins can quickly spot outliers and then go in and edit right in the list itself. Trees also kinda stole one of my ideas here. People favor simplicity. How many of you own an Apple product? Or five. Think about how much work went into making that device as easy to use as possible. But simple is always harder than you'd think. But what does that mean for us? It means that we cannot take the easy way out. If we take the easy way out, then we are making it difficult for them. We do it with change all the time. I haven't done much development in the last couple years. My world now is mostly all product-owning, project management, discovery projects. But every now and then I get the itch. So recently I hopped onto a project and found out that everything and how my company handles front-end apparently changed when I wasn't watching. All of a sudden I had to get node set up so that I can NPM. And I had to get Bower and Gulp going. Ironically I had finally just like two weeks earlier I sat down and learned Gulp, which last I knew we were using. Or I'm sorry, grunt. And even as someone who spent most of the past 15 years as a developer, a person who's dedicated to a lifestyle of constant change, I just got this feeling in my gut of, here we go again. A whole other ecosystem of things that I need to learn just so I can make one little CSS change. I felt this way because most people have some degree of fear when it comes to change. This is especially true if it involves a process that they do day in and day out and they've come to think of as routine. If you walk into a client's office and you talk to the stakeholders about building new software that automates parts of their job, they're gonna have at least some degree of anxiety. This type of fear and uncertainty to some degree is human nature. So if they seem angry or resistant to the change that you represent, don't take it personal. It's most likely not about you. But if you're ever gonna earn their trust, you have to be empathetic and accept where they may be coming from. Because people fear change, they will tend to cling to what they already know. Even if it means looking at the wrong solution to the problem. I was recently on site with a client. We had just started doing a fairly large Drupal site with them. And as we talked, I kind of uncovered a need for them. They had a need to store photos somewhere with a little bit of metadata. And as I talked to one of the stakeholders, she told me that they've been working on a FileMaker 4 solution. How many of you know about FileMaker and FileMaker 4? It was released in 1997. Some of our junior developers are almost as old. Or, you know, that solution is almost older than some of our junior developers at MetalTube. But they knew that system. As antiquated as it is, they're comfortable working with it. And in their experience, they knew they could make it fulfill at least some of the requirements that they had. And times have changed. And with them, expectations of public perception, what it means to administer content. Best of Breed services and solutions have spent years in an armor's race. Continuously one-upping each other on user experiences. As a result, most of your clients are gonna be a tad bit spoiled. How many of you have had a client assume it would be easy to do something they've seen in social media? Services like InVision, Shopify, Squarespace, take TurboTax for instance. Look at how easy they just kind of casually walk people through something as complex as paying their taxes. Now I've seen those tax forms. They really mask that very well. But make no mistake, that's what we're up against. That's what we're being judged against in our clients' minds. Now is that fair? No, absolutely not. But it is the way the world works. We have to be conscious of that as we make our interfaces. They're not gonna be thinking about the millions of dollars that some of these companies can throw at UX improvements. All they're gonna be thinking about is, well if it's so easy for me to do this on Instagram, why can't I have this in this business software that we're paying tons of money for? Unless we forget, people are vocal. They're gonna talk. And more importantly, they're gonna talk to their bosses about how they feel about this solution. At some point, the directors or C-sweets are gonna come down and say, hey, that thing we spent a ton of money on. How do you feel about it? And this is why long-term project success or failure can hinge on whether or not the people who use it like it. Even if the site achieves all of its goals, meets all of its analytics targets, the public loves it, your hard work can still fail in the long term if the people who maintain it hate it. It seems like a big world out there, but the bigger the client, the smaller the world. Some of our contacts out there, they can pretty much be the center of their own Kevin Bacon game of enterprise business. Having them speak poorly of a solution that you've created for their company, not only impacts within that company, your potential future work with that company, your own company's reputation, but as they spread out across other corporations, that can have a little bit of a ripple effect. And it may also contribute to, I'm sure we've all heard rumors out in the wild of Drupal admin not being very easy to use. Those rumors are out there. It can just contribute to that. So how do you make them like it? If you really wanna make your clients happy, you need to put yourself in their shoes. You need to see Drupal as they see it, not as a developer, but as someone who's going to log in and use it. When trying to figure out what a content administrator wants, the first step is to acknowledge your own limitations. We know software better than most people. I would hope that's our job. But people know their jobs. They know how to do their jobs, intricacies of their jobs, all those things that we don't know. The key is to meet somewhere in the middle. If you're willing to set aside many of your own opinions, put your own mindset aside, then we truly do have the potential to revolutionize their jobs. Odds are though, we don't know how to do their jobs. Generally speaking, they probably don't know what's possible, but by combining forces, you get the best of both worlds and everybody wins. So how do we do that? Well, we do a little recon. If the project is big enough or not clearly defined, I'd recommend you push for a small discovery project. Some people will call it a sprint zero, though that name sometimes is not favorable. This would give you the opportunity to interview system users directly. When you're talking through their requirements and goals, be sure to spend a little bit more time listening than you do talking. You'll have your chance to voice your opinions later, but make sure you take full advantage of this time to hear what they have to say. Hopefully, you'll consume that and be able to, that'll have a huge impact on the opinions you have and the solution you propose. And this is one of my favorites, get a demo. We're so used to going out and giving demos. We're always, especially those of us that do any type of sales engineering. You go out there and you show people stuff, you try to get them hooked and want to come in and do a project. But we need to get a demo. If they've already got something in place, let the client walk you through what they use today. This not only shows you a step-by-step process of what they're used to using, but frankly, it shows you exactly what you need to be significantly better than. So recently, we went on site with a client that had been using Microsoft SharePoint for years and then they were moving to Drupal. Yay. As they walked us through their day, day to day in SharePoint, I had to admit, SharePoint was actually a lot nicer than I thought it would be. At a very zoomed out level, it actually kind of reminded me of Drupal with Panopoli installed. Vaguely, on a broad sense, from their perspective. But having them give us that walk-through, it completely revealed about a dozen admin-based user stories that we hadn't been planning for. These were all pieces of functionality that the stakeholders had totally taken for granted. They didn't even think to mention it. They just assumed that we'd be doing these things. So prevent scope creep early. Use the demo as an opportunity to find out all the things they might not be explicitly telling you because to them, they're all unspoken expectations. If possible, actually go through the steps that they do. Maybe you don't a local or if they have a test environment you can play around with but actually load some content. Actually feel their pain. If they're coming to you, they probably have some form of pain point. It's one thing for them to tell you about it. It's another thing for you to live it. As you go through the steps, constantly be looking for ways that you can make the process more efficient. I love taking inspiration from other industries. Anyone here ever hear of method acting? Basically it's when an actor or actress will spend an extended period of time pretending to be the character for an upcoming film. Even friends and family for all intents and purposes, they are this other person. They do this so that when the camera rolls that character's just gonna flow right out of them naturally and organically. So years back I used to run the e-commerce and the IT for the world's first skateboard shop. Every holiday season the online orders would swell up to the point where the shipping department would call for all hands on deck. Every December I'd go down and help them pick, transfer, pack and ship orders. And then every year I'd make a list of all the things that were painful. All the places where we had room for efficiencies in our processes. And then every January and February, beaten and defeated and miserable from the holidays, I'd slowly lurk back to my office. And then I'd start to take action. Now all those things that I found to be inefficient, I'd start to plug all the holes in our processes. It's all because I spent some time down there with the users. Getting in touch with that actual process made every gap completely obvious. So method acting can be a fun exercise. You don't have to take it to the extremes that the actors do, but putting yourself in their shoes for a little bit is a great way to get in touch with what they're experiencing. And once you see the world through their eyes, it's gonna affect how you approach programming and interfaces moving forward. Potentially the hardest part of method acting is the exercise, or as an exercise, is forgetting what you know. You have to be able to put aside everything that you know and assume that you don't know Drupal. Always ask yourself, if you clear your head and say the thing you're about to say to someone that doesn't know what you know, will they have any idea what the hell you're talking about? If the answer is no, circle back and reword. Using framework-specific language, and I think we all know Drupal has a little bit of that, but using that type of language and expecting someone to follow you, I mean, that's like expecting someone who doesn't know Latin to follow a conversation in Latin. You're the one that knows both languages, so the weight's on you to translate all the Drupal speak to people speak. And once we feel like we've got a good grasp of our stakeholders' mindset, it's time to apply it. As you look at the screen, and oh, not this screen, when you're doing the development, when you're looking at the back end of Drupal, the content management experience, take a real objective look at that screen and look at all the pixels that you see. Are some of them not actually important? Do they not need to be there if you were a content author? For example, are they even gonna use publishing options or comment settings? Do not admins even need to see large sections of the admin menu or the management menu. If the answer's no, then simply clean it up. Take those things out for those people. As you work your way through the admin experience, constantly be looking for opportunities to streamline the process. For example, if they have a content type that's always gonna have lots of images, like on average, each node's gonna have 12 images uploaded. Do you need to make them upload one at a time or can you install something like Plopload? So how do you determine how to win at the admin? There are a few things that I like to assess when I start talking to a new client. I like to try to figure out how that client, in particular, how those folks think. And I try to group them roughly into what I like to call content management profiles. Depending on where they land on some key metrics, I'll start to steer the conversations and the tools I suggest for the admin around their preferences. Drupal was built to be anything for anybody, which is exactly what makes it such an amazingly flexible tool. But the downside is, is that out of the box, the admin area is so generalized that it's not really great at handling like any one specific scenario. While it can handle just about anything, it's streamlined for virtually nothing. So some key questions that I'll start asking folks, how often is the content added? They add in content every single day, is it every week, is it every month? How much value is placed on each individual piece of content? How quickly do they expect to be able to create a piece of content? We recently did a site for some folks that had red carpet photos being taken and they needed to be posted instantly. And are we talking high fidelity content here or is this just bulk data? And how tech savvy are the content editors? That's a huge factor in what tools we provide for them. Now granted, I'm gonna make some broad generalizations here about a few demographics, but remember these are just examples. You would apply this differently in your own context. So let's take a quick look at a few scenarios. Scenario one I call the brochureware. Let's say it's got 12 pages, three content types. Most new content consists of blog posts and they add a new post maybe once a week. Content admins are not tech savvy in this case. So if we chart that out, it might look something like this. For a site like this, their entire marketing strategy might hinge on a handful of pages. So those pages need to be relatively perfect. If they have internal staff, they're a lot more likely to be design focused and development focused. It's worth feeling out whether or not these clients are visually minded. And what impact might that have? Well, they might be a little bit more likely to enjoy clicking around to make their change edits in the front end. So if you're using D8, I mean Spark will be great. And if you're on D7, you might wanna look at Panopoli. You'll probably wanna spend a little bit of time setting them up with a decent Weziwig editor. And one important thing, if these people are very visual, make sure it's actually importing the CSS styles from the site itself. Otherwise, what they're seeing isn't actually what they're gonna be getting. And then keep the AdAdmin as simple as possible. These folks wanna spend their time making content, not using Drupal. So let's take a look at a very different type of site. I'll call this one the information site. Thousands of pages, dozens of content types, a team of full-time content entry staff, content added constantly. And so we graph that out and it might look like this, relatively the opposite of the example we just looked at. These folks are gonna be more likely to be overloaded with the amount of content work they need to do. They may be dealing more with bulk data as opposed to content. The distinction I make there, content tends to have a little bit more thought behind it versus lots of stuff we need to jam in quickly. These maintainers likely come from a world of spreadsheets and tabular data. Then you out there remember those old DAW space programs where employees can, or UNIX-based as well, where you could just tab through as fast as humanly possible, think of like your bankers. Yeah, those were really fast and really efficient to use. And it's really painful to admit that these days. But these people probably remember those times as well. In which case, you know, we're really competing with the clock at that point. I mean, you're trying to make it as efficient as possible for them to do a job. So look at a few inline editing options like VBO, editable views, there's some stuff out there that can help with that. If applicable, maybe even look into options that allow for quick imports of information from outside sources. You know, we had a few content admins on a project recently where every week they received an Excel spreadsheet that had all this list of information that they had to manually convert to nodes. Well, that's, you know, the easiest way to make their admin life easier was to give them the ability to upload that Excel sheet. They just upload it once, the nodes get generated, and then they just go in and make any edits that are necessary. I also recommend you take some time and check out the great work the commerce guys have been doing on Commerce Kickstarter. You know, they're dealing with e-commerce folks, people that deal with lots of products, people that wanna be able to, you know, do that scannable browsing of a list. You might be able to get a little bit of inspiration on how you might wanna approach some admin stuff yourself from there. Also a plus side from this scenario, these employees are full-time employees. So you might be able to make some broad assumptions that they're gonna have some training available or the opportunity to do some training, and over time, they're just gonna get more and more efficient with the system that you provide. Quick overview of a few other profiles. Now for you, in the context of your clients and the types of industries that you commonly work for, you would wanna come up with your own, but just to kinda spark the conversation, you know, these are some other like user profiles that I've kinda grouped into groups of modules that we'll use. You know, speaking of commerce guys, of course there's the, you know, commerce site. This is a group of people that are running a business. They're gonna wanna be able to maintain products very quickly. They're not gonna wanna be able to have to click through the site most likely. Products are probably gonna have variants like small, medium, large versus red, blue, and green. So there's a lot of content management to think about there. And plus, you gotta keep in mind with those folks, they're also competing with Magento, which has an admin that while kinda confusing at first is incredibly powerful and purpose built to be an e-commerce system. Then there's the community site. I mean, that's gonna be all the content provided by the site visitors. So of course then you're gonna wanna kinda double down the effort on making things as simple to administer as possible for anybody. The maintained by developer site, that one's kind of a double edge sword because one, in some cases, you might actually not lock things down as much. You might leave a few doors open for them for later. Or the exact opposite might be true if you're gonna continue to support the site after launch. And then there's the, our content lives elsewhere site. And in this case, it might just be, you know, synchronizing data in from an external source. There might be some work around providing workflow and approvals or the ability to extend, augment that incoming data as it's received. Sorry, let's get practical. We know our people, we know what to do, or you know, we know what to do with that logic. Now, how do we tailor this admin experience? Luckily, Drupal makes this extremely easy for us. I'm not gonna go down the cliched route and say that Drupal's like Legos because I've already did that in another talk. But I'm gonna compare Drupal to Sculpting Clay. Sculptors can get a brick of clay and mold it into anything they want. Drupal is not purpose built. And when it's installed, we can kind of do whatever we need to do to make it become whatever it needs to become. And when I came to this industry from the commerce world, that was mind blowing to me. You know, coming from Magento and various other cart systems where it's not really super easy to configure and change that. And while that's amazing, it's only amazing right up into the point where you leave Drupal's admin as it is out of the box. So first tip, make the admin part of your overall plan. Factor it in very early in your planning. You know, you have to plan for it before you start building the front end. Because you've gotta make some big decisions. I mean, are you dealing with panels or blocks? Even from that level. I mean, that's gonna have a huge impact on how people will maintain their site. And you've gotta factor in the broader architecture decisions. If you don't, you're gonna end up at the end of the project and if everything's confusing and no one knows how to use it, it's probably gonna be irreversible at that point. And keep the admin simple. I say simple in regard that do not let easy access to complexity cloud your judgment. Drupal is very easy to extend. Which is why we love it. But it's also very easy to just start throwing modules into it and turning them on. If you just start stapling things on and let it get sloppy, it's gonna affect performance, it's gonna affect a lot of things. Try to solve complex problems with simple and elegant solutions. Which may or may not involve complex code. A lot of times it's just a matter of configuring what's already there. Generally speaking, the things that you're adding to Drupal admin experience should actually be taking things away. As opposed to adding more complex things to the workflow. You can probably eliminate a good 60% of user confusion just by actually utilizing roles and permissions. So a few minutes of configuration of these settings can have a huge impact over what a content author sees versus what a developer sees. So we recently started working on a client that had already had a Drupal 7 site. We inherited this site. And it's a common story. Every user was an administrator. And one day one of their new employees accidentally deleted a field instance from a content type. But whose fault is that? Should that content author, even if ever even had access to the structure menu at all? Probably not. So on that note, what people don't see can be equally important as to what they do see. So look at all those links. If I know nothing about Drupal, that's a lot of pixels in my face. If we did our job gathering all the information and we know what types of user roles they have and we know what each user role needs to be able to access, we can very easily minimize what's even being presented to them to make it very clear where they need to go. And with just a little bit more configuration, we can narrow that down even further. It's gonna be really hard for someone to go down a path that they're not supposed to at this point. Custom content views are probably the second easiest thing to do that I commonly have seen not get done. I mean, even if you're using something like in-place editor, there's still gonna be a lot of folks that prefer to go into the back end and actually just edit in this type of experience. But there's lots of great options Drupal provides, just by doing exposed filters, you can sprinkle in some views, bulk operations, there's some great stuff there. Think back to your interviews. Are you making their jobs as easy as you can? Have you provided them with all the columns that they would want to see in order to make the decisions that they need to make? Can you create a to-do list for that day just by providing a filtered view? For example, give a photographer a list of all the new products that have been added that have not yet had a photo uploaded. Or giving content approvers a view of all the new posts that the authors have recently created that have not yet been reviewed to be published. You know, why make them search for all this stuff, all these common tasks, these things they're gonna do day to day when you can simply take a few minutes and set up a view. The minutes you're gonna spend doing this for them could probably save them maybe even hours each week. And we probably should not assume that people will learn views. It's a safe bet that if they came to you, they probably did so that they don't have to. And to the non-text, you know, the folks that are not super tech savvy, let's face it, views can be very intimidating. Hiding DrupalSpeak, it's all keep in mind Node, Entity, Taxonomy, Panel, Context, Views, even Modules. I mean, these are all words for us. They're not words for them. You know, update the management menu links when appropriate. Use things like jammer and string overrides. You know, that'll help you kinda tuck the Drupal a little bit under the hood for these folks. Again, I love taking lessons from other industries and that includes journalism. The old inverted pyramid, most important stuff up top, work your way down to the less relevant. How often are they going to edit certain content types? Ones that they're gonna edit all the time should be very accessible. You'll probably focus some nice, you know, custom views in the management menu for them on those types. Versus ones they're not gonna do very often. Maybe you put a little bit less effort into that. Or things like configuration settings. You know, those can be accessible only to true system administrators. And then the same kind of applies to fields. There's rarely a time when field groups module is a bad idea. You know, any website that has more than a handful of fields on a content type, put in field groups. And start to actually organize content. All the required fields should be very prominent at the top of the form. The things that they're going to almost always have to provide on every node should be grouped together and very upfront. Optional fields, things that maybe some nodes might have every once in a while. Push those down to the bottom. And dashboards can get a really bad rap. And I don't, you know, I kind of buy into this too. Because so many software products out there, everyone wants to have a dashboard. And they build dashboards just for this little check box to say that our software as a service has a dashboard. And as a result, they usually put really mediocre content in there. And we walk past it just like we do an end cap at the store because we know the aisle of the product that we want to buy. But, Drupal has a great dashboard. And you can leverage that. You can make a lot of those custom views. You can make those little to-do lists, all those things you can have right on the landing page of the admin. This one dates more back to D7. But make sure you've got a good decent admin menu in there. D7 made you kind of click your way all the way through the hierarchy, which is kind of needlessly painful. And there's several options out there. D8's nav bar is great. And there's a back port to D7. Adminimal has one as well. But the important thing is that you reduce the number of clicks that it takes for the users to get to where they want to go. And don't be afraid to try another theme in the admin. This can be a quick win. You know, make sure you get one that's specifically developed to be an admin theme, like Adminimal here. You know, the alternate themes, the outside of the ones that come with Core, you know, they're generally gonna provide a stronger visual aesthetic to the admin interface than your, you know, it's probably gonna be a much more contemporary-style design. But do be warned, however, you know, a lot of the ones we've tinkered with at Metal Toad, we found, you know, they're not quite as battle-hardened as the out-of-the-box admins themes. They tend to handle, you know, Core very well, but sometimes, you know, you'll run into some conflicts on config module, you know, contrib module config areas. So just kind of be aware, like the more off the beaten path you go, the less, you know, the less downloads you're seeing, the less commits, the less activity on an admin theme, the higher the likelihood you're gonna need to make a few patches. When appropriate, when the clients needs dictate it, you know, there's some powerful tools to take the content administration right into the front end. D8 obviously does this brilliantly. You know, some people love the idea about being able to browse around the site and just click on something and edit it right there. No confusion. But make sure it's a good fit for them. So a few years back, I spent, what in hindsight was way, way too long, making sure that some custom features for a client were all fully functional in the in-place editor. I pretty much blew my budget for that and that really translated to my own nights and weekends being not as awesome as they could have been. Three years later, this particular client has still yet to actually use any of that stuff I built because they just aren't that type of client. And I didn't know that. You know, it was a requirement that it had to do this and it just got done. And they just don't browse the site and edit. That's not their style. However, on the flip side, you know, I found on many occasions, you know, when I'm talking to potential clients and customers, putting together a quick Panopoly demo, that can generate a massive amount of excitement. You know, there's some people, when you show them that power to just click and change the layout and just drag and drop panes around, I mean, they get so excited to buy that. And I was very excited to see in the keynote this morning, you know, some of the stuff that Dries was proposing. I mean, I have several clients that would drool over those things. But then there's the polar opposite, you know, the browse and edit mentality, the spreadsheet editors. Any of you have a client out there that uses Excel a lot? Because it's incredibly flexible. You know, anyone can go into Excel and manipulate data, columns, rows, they can, anyone can do it. And sometimes the benefits of that outweigh having that single source of truth with their data. These people, if you go to them and tell them they need to browse around a website and click on things to edit them, in their minds, they're gonna think, you just made my job take 100 times longer. So for those folks, you know, think about tabular style bulk editing. You know, as I've mentioned, as we were talking earlier, you know, under the content management profiles, you know, look into things like VBO, use bulk operations, look into some of that stuff commerce guys have been doing. But overall, I think Drupal still has a long way to go to make these folks happy. I'm gonna be very interested to see how things evolve in Drupal as it continues to go deeper into the enterprise space. And I think Drupal is getting really close to solving a lot of the, you know, content authoring experience of the folks that wanna do the front end stuff. I mean, we're gonna reach a point here very soon where Drupal has nailed that. And then I think we're gonna start to have to make some of these folks happy. So I don't really don't like to do this because I feel like maintaining lists of modules is very difficult. And it's gonna change next month anyway. But I wanna give a quick nod to the hard work that some of the people that have contributed these modules. And I'll be uploading these after, so don't worry if you miss a few. But a field group, field collection, field validation, media, rabbit hole, revisioning, workflow, jammer, link it, login to bargain, draggable views, entity queue, inline entity form, shortcuts per roll, chosen, add another, custom contextual links, responsive theme preview, wazzy wig, usually with a CK editor library, administration views, nav bar, add minimal menu, link checker, pathologic, content menu, plop load, and bootstrap tour. These are just some of the ones that we've been favoring at Metal Toad for some projects, not all, but some. But this is great, but how does this become a reality within your business? Because let's be blunt. All this stuff I talked about could be very difficult to justify to your clients and getting them to pay for it. Fact is, it's typically considered to be a much lower priority. So unless the main focus of the project is a portal, specifically meant for the creation of content, odds are you've got a public facing front end that's gonna hog all the priority. And when the iron triangle gets strained, deprioritization of the admin section is a very easy release valve for all that pressure. As recently having a casual conversation with the director of development for a large hardware manufacturing company, she was relating to me the struggles of the internal stakeholders, trying to get them to buy in to the importance of one particular UX improvement. She felt that they could literally save from a three minute process. She felt that it was completely feasible to get that down to 30 seconds. All they had to do was invest in a couple more sprints of development. Now, if you just think of the long-term savings over several years of taking that 2.5 minutes off of every widget coming off the assembly line for a Fortune 100 company's manufacturing process. We're not even talking about millions of dollars in savings. She was actually talking about billions of dollars in savings. But people can be short-sighted. It seems absurd that with the cost of two to three sprints right now being able to save that much money over time that that was not just instantly approved. But such is the way of business sometimes. But that is turning around and we can all take comfort and there is a movement gaining steam around this argument that it is worth putting some time and money into making these improvements. Some practical tips. Change your mindset when estimating to include time for the admin of each feature. I think we all think about the feature. We all think about what it's gonna do. But we gotta remember part of the life cycle of that piece of information of that feature is the information getting in there. And we gotta build that too. Actively account for this time when you're writing your scopes of work. This should be represented as dollars as part of the budget. And do not wait to the end of the project. If you wait to the end of the project you're not gonna do it. You're not gonna take the time because something else is gonna take the priority. So make the admin improvement subtasks. For each story that you're working on part of acceptance should be that it's easy to administer. And whatever context, whatever flows with making it easy to administer should be part of acceptance criteria. Show off the progress in your demos to your clients. When you're doing sprint review show them the full life cycle from creating the content all the way up until it's displayed so they can picture in their minds and their thinking of this as part of what they're buying. Talk to them about the entire life cycle of the project. Now it's one thing if you're doing a quick small website for an event. It may last for a few months and it might be end of life. But if what you're talking to your client about is going to be expected to be around and used for several years start talking to them about things like employee turnover. How hard do they want it to be to train new employees over the next several years? And don't just tell them about it, show it to them. I talked about the emphasis of getting a demo but you gotta give as well. I mean you gotta show them how much easier you're making things for them. Establish an actual awareness within your company. Empower your employees to cultivate empathy towards the stakeholders needs. Have some standards around admin experience. Have your team wanting to strive for reaching those standards. Always plan to implement a bare minimum. I mean at least, even for a small teeny tiny, five page site, at least spend two to four hours to do some configuration changing. Even if it's just roles and permissions and a little bit of touching up with the content of you. So have a minimum effort. And then hopefully ask yourself shouldn't you do a little bit more than the bare minimum for your clients? One easy way to establish a bare minimum is to create and maintain a company installation profile. This way every time you break ground on a new site you're already kind of able to bake in a lot of your company's default opinions and best practices. Metal Toad, we've kind of gone a step further. We even have a small little shell script that we use. It goes off, sets up environments, sets up the get repo, deployment processes. It sets up Drupal based on our installation profile. So literally in seconds we go from absolutely nothing to development ready with our company baseline opinions already baked in. Now yeah, we still gotta do a lot of work and all those questions we asked and evaluation we did of our customers are gonna make us have, we still have work to do to custom and tailor the admin experience but we've at least got a huge head start. And if you tend to work with multiple, like clients in multiple industries, specific industries, it might not be a bad idea to make a couple of these just so you can kind of spin up different ones very rapidly. And of course, like anything in our industry, the second you stop moving is the second that you're outdated. Continually reevaluate and modify your company's opinions around Admin UX and check in with stakeholders a few months after launch and ask them if they've got any pain points. Retro with them, learn from the ones you've done in the past. So to sum it all up, if you've done your homework on your applicable people, if you've done your method acting and you've put yourself in their shoes, the most important part of all of this is you have to ask yourself, would I want to use this? What would be frustrating to you? What would you feel to be repetitious? What would cause you to think at the end of a work day? Man, if that was just automated, I could have been out of here hours ago. Then channel your inner content author and ask, how can I make this easier? How can I make it better? And then go and actually do it. Always remember, Drupal provides all the tools to create rich content management experiences. It's up to us to use those tools. And it's up to us to empower the people. And to empower the people, we need to think like the people. All right, should I have a little Q and A? And I think I'm supposed to mention, join us for sprints on Friday. And of course, I would love any feedback.