Welcome to the nonprofit show. We are thrilled you're here with Anne McCauley Lopez, SEO content writer at Agency Content Writer. She's back with a thought leader episode to talk to us about what it's like to create a content strategy. So stay with us because Anne, as always, has a lot of really good insight to share. Hello to you, Julia, CEO of the American Nonprofit Academy. As of you watching and listening, that's Julia Patrick. I'm Jarrett Ransom, your nonprofit nerd, CEO of the Raven Group and honored to serve as co-host day in and day out as we have these conversations. And that bright, bold yellow means it's a thought leader episode. So it's an extra special episode for today. We wouldn't be where we are if it wasn't for our amazing presenting sponsors. So thank you so very much. We extend our gratitude to Bloomerang American Nonprofit Academy, your part-time controller, nonprofit thought leader, fundraising academy at National University, staffing boutique, nonprofit nerd and nonprofit tech talk. Do us a favor, but do them a favor and really yourself a favor.   I like that, Jarrett. That's a cool way to put it. Hey, we have the latest and greatest download the app, the nonprofit show app. Thank you, Vanna White. Julia likes to show her phone at that queue, but you can absolutely scan the QR code right now on the screen and it will pull up the app in just a few hours after our conversation with Ann. You will get the notification that the broadcast is now uploaded in live and we're still on podcast and we're still on broadcast. So you can find us pretty much anywhere you like to gather your entertainment. So I still like to say we're working on that hologram, but who knows, that might be here before we know it. Very soon, very soon, my friend. So Ann, we are so thrilled to have you back. Ann McCauley-Lopez for those of you watching and listening. Again, Ann serves as SEO content writer at Agency Content Writer. Welcome back, my friend. Thank you. Thank you. I haven't had both of you on in quite a while for one of my episodes, so it's great to see you both. I know. That's right. We are here for it. We've got a lot of great insight to share and really looking forward to learning more from you. So let's dive in because there is a lot to cover when it comes to creating content strategy and one of the things that I think about immediately, Ann, is there is so much noise out there, right? There is so much content, right? There's emails, there's texts, there's phone calls, there's the web addresses. So I love that you have here. Let's identify categories. So take it away and share with us what it's like and those best practices. That's a really good point, Jared. There is a lot happening and I think when we talk about creating content, we're talking about creating content for all of those.  A lot of times it really should over arch, right? So today we're talking about content strategy. I'll be writing a blog post to share what we talked about and that sort of thing. So that's really what we want is to create a sometimes or mostly cohesive plan that we can follow. So I would say start out with the knowns. What do we know? We know we want to send a newsletter. We want to have a podcast or we want to have a blog. We know our audiences, like think about your audiences throughout the year. We might not be writing to all four because that would be really hard, right? Like donors and volunteers and, and, and so that's why I said kind of pick those audiences that you want to talk to and then that way we don't forget, right? Because there is so much out there. Then we don't forget who we are, who we're talking to. So for volunteers and non-social media, you might find an article that talks about the health and well-being of people who volunteer, right? Does it make us a little healthier, make us smile or make us feel like we're giving back? Maybe that's something you post on social. And along with that kind of volunteer spotlight week or month, we can include that article as well as a spotlight of a volunteer or a group of volunteers and like corporate volunteers or something like that. So we begin to tell the story of what the nonprofit is doing and what the mission is, but really be strategic. Like, okay, this, we know we have an event coming up and we'll have volunteers. So maybe we kind of have a, hey, we're looking for a volunteer, you know, like leading up to that event. So we're not talking to everyone. That's so confusing, right? If we hit all four of those every single day, I'd be exhausted by the end of the week. You know, and I'm fascinated because I think of content strategy as coming up with what are the stories you want to tell first and then trying to plug them in. But I like this a lot more. I think this is so much smarter to figure out who you're going to talk to first. I love this approach. I really do. I think it's a really good idea. And it seems to me, it's almost, you know, Jared and I talked about this from the beginning, like, and I think you've helped us understand this, you know, the avatars, who is it that you're trying to talk to? And then navigating in that direction is very, very interesting. I like color coding on a spreadsheet. So one of my projects this week is to do my own social media, kind of put a calendar together for myself. I'll be honest. I'm behind on that. But you can start at any time, right? It's meeting in June. So let's just start it in June. Like I want to get in the habit. I do have a spreadsheet. I like color coding. My last corporate job, we worked off spreadsheets and used color coding. So I still kind of stick to it. Whatever works for you and your team, do that to be organized. Like you said, Julia, and then start kind of backfilling. Like, what will we need for the gala? Well, we'll need to do a volunteer call out. We'll need whatever it is, kind of back things up for what you'll need and track it and make sure someone's managing that. Right? I was just talking about the HOA before we came on and we have a spreadsheet where we track everything we're working on and it makes it a lot easier because everybody has access and I'm kind of the manager of that sheet. So it's the same for your content strategy. Content strategy, she's going to have more colors though, right? It's going to be way more fun than an HOA spreadsheet. So are you kind of giving us permission to start something literally just on a spreadsheet that we don't have to be investing in additional content management software that it can be as simple as kind of starting that way? Yeah, I'm all about keeping it simple. Now, if you're on a platform like a HubSpot or another platform, maybe that's non-profit specific, if what you're using has that functionality, give that a try. There's other things like air table, which can interact with other spreadsheets. So maybe the marketing department has something you want to pull in or whatever it is, work with what you have and who you have. So if they've already got something laid out or they're working on their calendar, pop onto that and grab some ideas, maybe connect your sheets together or whatever works for you. But I really think like I think in 90-day sprints. So my year is I do like a 90-day year. So I track how far have I gone in the last 90 days. So I think for non-profits, we look at the whole year, but when we're really getting down to the nitty-gritty, let's maybe look at 90 days. Or July, this is the last month of the year for a lot of folks, right? Yes. Yeah. So now, so June might be a really good time because then you start July is your new year and start the habit of having it. It doesn't have to be a lot. Like I go on LinkedIn a couple of times a week. I go on Instagram kind of as I travel really as I have photos or when I post new content, we go on there when I'm a guest, I reshare, that sort of a thing. So it doesn't have to be over complicated. If you're doing, you know, if you're putting blog posts and newsletters, you know, share those and ask people to share them on their profiles, like your volunteers. And if you have a staff, have your staff share it out. The more eyes we can get on it, you know, the bigger it makes our community. It's kind of like online networking or as you're out networking too. But I think if we, I'm going to do this myself. So I'm going to let you know how it goes. I'm going to take a deep breath, not going to freak you out. I'm going to create a template and I'm going to throw, start throwing in what I know and the content that I want to be creating or I've already created so that I can start sharing that out. And then from there, I feel like you kind of have a skeleton, a plan. And I've always said, Julie and I, you and I have always said, like, kind of keep space on there for other things that happen. That was going to be my question. Yeah. Because like, I know Jared and I've talked about this in the past.  Meaning you can always, when there's some bad news, you can always make it to your advantage or run to the fire, basically, you know. So what does that look like? How do we give ourselves just grace or do we like leave open spots or how do we identify that? Sure. So I think of it if I were managing a food bank, for example, typically what happens is the shelves kind of empty out in the summer months, right? Everybody gives over Christmas and Thanksgiving. So you might kind of put a tentative. Do we need food for the food bank? Do we need donations of a certain kind of food? Do we need, you know, we're collecting things for back to school? Well, what does that look like?  Obviously. But what's kind of a maybe? What do we think is going to trend put that on there? If the shelves are full, fantastic. But if they're not, and typically they're not right for food banks in particular, then let's do a call out and let's say, hey, we need this. If not, then put a thank you out there in all like bad news or good news. I think things like, you know, I just heard a report that because of the drought in Arizona, Yuma, Arizona is the highest producer of leafy greens for the country over winter. So what does that mean? If we don't have those leafy greens for your food kind of based nonprofit, I must be hungry because I keep talking about food. But that's kind of what I think, like, do we need, yeah. Yeah, I have a question about this. So for a lot of organizations, right, they might be creating this from scratch, but others, I'm curious if we can rinse and repeat the same like content calendar year over year by making some changes, right? So like if the Gala has moved from November to September, we obviously need to change those dates.  Yeah, great question. Yeah, very good. I'll tell you a big secret. I have a friend who basically kind of serves as my accountability coach. She told me her secret and I'm totally stealing this idea. She has evergreen content and that's content we can post over and over. So if it's articles about volunteering or articles from our own blogs or from the media, we get some media attention. Post those again, right, over and over. I watch her content and I didn't even know she was doing this. That's how good it is. So build in like every second Tuesday and fourth Tuesday. We post about this for mine. Be on the lookout. My dog is the employee of the month. So I'm just going to drop posts in every month for him. Love it. It'll be a similar graphic. We'll change it from May to June.  We're all about the mission, but the more eyes we can get on that again, it grows that online community for us and it saves you time, right? If we can rinse and repeat, as you said, and post the same content or move that column of October gala over to September and then say, OK, we've just got to clean it up and change the dates, but use the same messages. That's where I think I think we've got we wanted to touch on chat GPT today. I had done an experiment. I talked about the last time I was here and I pulled up. I said, how did I say it? Social media posts for nonprofit gala. And it gave us blanks to put the date in the mission. You could add who it benefits with the hashtags already there. And so you take that this year, use it again next year. I mean, double check the hashtags, maybe adjust a couple of things like the date. But if it's to benefit the Boys and Girls Club, let's, you know, put that in there and use, I think, to use the tools that we have. Like we already have some content built out. Let's do it. Let's see on the technical side, go to your web person or you know, if you've got a marketing person, somebody that looks at those Google analytics, what is, what do people really like to read about? And it might be content that's not really search engine, you know, SEO, optimized search engine, optimized, optimized, excuse me. But it might be it just performed well, right? Jared, we had a grant station article, you know, what to do when the grant maker says no, that did really well over there. We know that. So we repost it, right? We share it. We say, you know, we refer to it. And our new blog posts, I do write for Jared. We all know that. We admit that every time I'm here, it's out every time I know. And I think it's out. Well, we know that post performs well. We know what posts on your website perform well. And so we want to maybe write more content like that. So take what you know and what you've already created and absolutely definitely adjust for the new year, the new quarter. I'm telling you, I stalk my friend. I didn't even know she was doing this. I love I have a question about this. And that's it's more a little bit more technical. And are you saying should we like write new headlines and decks for that content? Or should we be like, oh, we've talked about this. I'm going to repost an article from last March. I mean, how how do we do this? I mean, do we do we quote ourselves in essence? Or do we repost it as it looks like something new, but it's not really posted as new? Yes. OK. And now that I know my friend's secret, I go back and look and it's the exact same post. There are just some types of content you can just post again. We need volunteers this weekend. We need whatever it is, your backpack posts to fill the backpacks. Use the same ones. Maybe if it's a date oriented thing, change the date, obviously. But there's some content that just just grab it, copy, paste. OK, I totally agree. And I'm I'm working with a client and we have very little capacity, as I know, a lot of development teams across the nation do for nonprofits. And I, you know, and I told her, I said, go to the email blast that was sent out in July of last year. See what was on that newsletter. See what social media was posted, right? Because they didn't have a calendar created. So they they didn't have this system to track, right? And I'm like, I'm all about this, right? Like repurpose, reuse, recycle, because a lot of it is evergreen and it's seasonal, right? To, ironically, a food bank that does in the summer. So I'm right there with you. One of the questions, though, as we talk about capacity, who is responsible for this? Because I love that you talk about engaging your team and engaging volunteers. But how how do we best do that? I think one of the things actually I was inspired by one of your posts, Jared, and I know we refer to it quite a lot. It was how do you engage your board and the idea was make a list of of things you need done or would like them to do and have them pick and hopefully you've got somebody in there who's a writer or who wants some writing experience, maybe, you know, volunteers. Maybe they want some writing experience so they can take to their job or so they can write their community newsletter, you know, their H.O.A. newsletter, whatever, give them the opportunity to write, give them some guidelines, perhaps, so that you've got maybe it's raw information, but you can take that and do a quick edit and use that for a newsletter or quote them or if they're able to write that full content, have them have them do that. Who on your team?  You know, if they're in accounting for nonprofits, maybe there's an article they'd like to share. Like, do you have something related that we can post? We're getting our calendar ready for the coming quarter. That is so good. And I'm going to, like, totally out myself. I never, never would have thought to ask the finance director, right? But transparency of financials is so critical in the nonprofit sector. Yes, thank you, Anne. This was a huge aha for me. It was like, of course, you also ask the finance team. Yeah, and I bet to to Jared's point, I bet that never happens. Never happens. Oh, go to programming, go to fundraising. Yes. Yes. Absolutely. I mean, you never know. I was thinking about it, like from a corporate perspective, they talk about like shuffling teams and, you know, you have a good employee on this team, but they actually have an interest in marketing. Well, instead of laying them off, bring them over to marketing because you have a spot open there, you know? And so I kind of, I think you can apply the same in a nonprofit. I'm sure there's volunteers or there's like a journalism student from a local university or a high school journalism student who you could engage to do some work on as a volunteer or if you've got the budget to pay them a little bit, do that. But yeah, I mean, I think you never know. You may end up maybe with a little bank. So I had written for a cancer nonprofit and focused on patients, primarily. And so we had a little bank of patient stories and all we had to do is, you know, make sure we had their sign off that we could post their story. Usually we only use their first name just for privacy. This is a crazy world out there. Some of the names changed, but it was a nice way to dive in and say, oh, yeah, let's post a patient story. Like what better way to do fundraising than tell how what we do impacts. So it's a fundraising story. It's a story for the donors. So if you send out a donor newsletter, here's so and so story to make an impact. And we have a little bank of those. We have a little bank from it was patients and research. So we had a little bank of research, letters and updates. We'd ask them annually so we could go back and maybe do a video interview or something like that to get content knowing that that was in the news. You can post a news article and refer them to that article on your website and just kind of tie it all together. I think if we think about it in terms of like, what's our January newsletter? What's our quarter one newsletter or our like for nonprofits? The summer newsletter, right July, August, September for the new year. What do we want to focus on and then focus there? We don't have to focus everywhere because it gets like even just saying that focus everywhere, I have a little bit of anxiety, right? Like that's a lot too much. Yeah, like we know the mission and the vision. We know the voice or the brand. So if we have different writers, they should be familiar with the organization and maybe read through some newsletters kind of just come up with a quick little. Here's what we ask for our writers to do or our contributors. And that way, you know, like you could put a Google alert like I could be in your finance department and put a Google alert up for whatever the focus of the nonprofit is. And if I see a newsworthy article, oh, now I know. Oh, I send it to Jarrett because she's managing that spreadsheet. Right. And then when you get that email, drop it somewhere in. If it's appropriate, drop it somewhere in. I tell people, I'm like, you don't always have to have original content. You can use other people's content, but use the best of. So it's telling a story that relates to your organization, drop it in. And that could be one of those evergreen posts. Like food banks are always short in the summer. Like our our shelves are historically empty. Here's how to give and that can be an evergreen post. Absolutely. One of the things and we don't have much time left, but I want to make sure that I get you to talk to us about generating hashtags and headlines because we can do all this work. But we've learned from you and Macaulay Lopez that if we don't work on this hashtag and the issue of SEO and the headlines, no one's going to see it or not. You say no, but fewer people are going to see it. Help us understand this. Sure. So the headline should contain a key word if you are a keyword phrase. If you're doing some focused content, telling the story of somebody with who has benefited from your organization, for example, who's volunteered with the organization, that's storytelling. And I think that's more organic SEO where we want people to know that that happened. If it's kind of more, you know, how to donate to or benefits of or something like that, the headline should have a key word. And we we might think in terms of having some of that type of content as well. And then when we put it out, we want to have some hashtags. I use chat GPT for hashtags. And I literally said hashtags for I think I use travel blogger just to see what it what it put out when I did it. I did that social media gala post. And within that social post, it actually had some hashtags and it had some suggestions. So like if it's a gala in Phoenix, in Minnesota, in Texas, you know, Houston, Texas, with the name of the city, Houston gala, Houston fundraiser, things like that. And chat to B.T. showed me that and and suggested that. Now, does it know everything? No. And there's other websites and the name of them is absolutely escaping me. I put in for headlines, I say headline analyzer, freed headline analyzer to kind of test out my headline. If it's something that, you know, it's kind of newsworthy or we want to let me do it for some search engine searchability. We might do that. But those are ways, I think, to to kind of safely use chat GPT and what we're doing and also lighten the load like everybody's tax, which you have those resources like I keep a running spreadsheet of my own or a bookmark them and make that available to your key people. But have somebody who manages it as well so that if maybe there's a better tool or a different way to track, they can make those changes.  So maybe lock down the tracker, but have a place where people can kind of drop their resources, something like that. Love that. I love that. And I feel like the tracker also creates a content inventory, right? Like what have we done? And again, outing myself since I started my business in 2009, 14 years ago, I have a lot of content out there. And so how can we be smarter by using that system that we're using to track the headlines that have, you know, like really knocked it out of the park? So getting, you know, these systems into a place again where it's just building systems and maturing the systems that we have. So you might be updating one of those old articles, too, and posting it as a new article and referring the articles to each other. Oh, interesting. Not hard. Yeah. Yeah, referring, yeah, referring them back. You know, I want to refer our viewers and listeners to agencycontentwriter.com's blog. There are amazing, amazing articles so that a lot of them will have something. There'll be topics that we've touched on here on the nonprofit show with Anne. And in some cases, lessons, things that she's learned or she's doing, it's wonderful, wonderful information. And you can access it for free. Go to agencycontentwriter.com. And Anne, you're so obviously this is your business, but you're so beautiful at getting these things updated and current and it's just an amazing amount of information. Anne has also written a book. It's really moving. We don't get to wring the bell. My CML story. Check it out. It's really a cool thing to see and to to know a little bit more about the journey of somebody who you work with or you're familiar. Sometimes you think you know them, but you don't always.  I learn something every time from you. Every time. And it's really cool. Thank you. Yeah, it's really amazing. And I think the biggest thing, Jared, for me, is that she reduces the fear and the stress. She makes it seem approachable and something we can do. Oh, absolutely. I mean, I do need to make an apology to all the finance directors I've ever worked with. But I think I can do that. And then now you just incorporate it, right? When you know better, you do better. I love it. I think you're right. When you know better, you do better. Hey, if you don't know us, I'm Julia Patrick, CEO of the American Nonprofit Academy, been joined today by the nonprofit nerd herself, Jared R. Ransom, CEO of the Raven Group. And again, we are here because we have the amazing support of folks like Bloomerang, American Nonprofit Academy, your part-time controller, nonprofit thought leader, Fundraising Academy at National University, where I hope you were with us, Jared, broadcasted from there twice last week, which was super cool. Also, our friends at Staffing Boutique, nonprofit nerd and nonprofit tech talk. Again, these are the folks that allow us to have these conversations day in and day out. And content is queen as we have learned from Anne McCauley Lopez. Anne, thank you so much. Thank you for having me again. It's always fun and the time always flies. It does. It does, even for us. And as much we do this every day, even we are surprised at how fast it goes. So it's been amazing. Hey, everybody, as we end every episode of the nonprofit show, we want to remind everyone to stay well. So you can do well. We'll see you back here tomorrow, everyone. Thank you, ladies.


Hey guys, welcome to reverse 1999 and we have a announcement that the CVT will be reopened. This was done three hours ago and here are the participation methods. So you have Android and iOS PC is no longer, I think available. So only both Android and iOS are going to be available for testing. Note that there will only be 3000 players added to the beta. So this is first come, first served. Once the registration has been reached, then it will be closed automatically. So I will put the these links here in the description so that you don't have to go through where it is. It's actually in the official Facebook page of reverse 1999, but you can actually check it out in the description below. So that is it guys. Hope to, you know, hope that you guys will be in the CBT and will be able to get a first hand look and feel of the game. Thank you very much for staying this far.  It's The Warden and I'm out of here.


Hello. Welcome to Absolutely Necessary, Powering Mobile Apps with Drupal. For agenda today, we're going to talk about mobile apps. Why they're considered mobile apps and why they're important. Architecting, we're going to touch on various mobile architecture approaches and Drupal's role, where we'll discuss leveraging what Drupal does best and modules that help use Drupal as a backend for your mobile app. But first, let's introduce ourselves. I'm Amy Novica, a software developer, and I'm here with Greg Schoenfeld, a software architect, and we're phase two. A good portion of you probably already know us as we've been in the Drupal community for 20 years. But if you haven't heard of us, we're a digital product agency passionate about consumer experience grounded in data insights and rooted in two decades of successful technology delivery. We make digital products that inspire, engage, and create impact. Along the way, we guide industry leaders towards what's next in their digital landscape. So, what are mobile and native apps? Mobile apps are downloaded from an app store or similar marketplace and installed on a device that includes phones, tablets, or wearables, and the most popular operating system for these are iOS and Android. So, I'm sure most of you know many, many mobile apps, but allow me to give you some examples along with features that make them unique. So, one good mobile app is an American Museum of Natural History Explorer app. What it does is it leverages location and wireless technology to allow visitors to learn more about the exhibits that they're actively experiencing as well as be a virtual guide throughout their tour. Another good app is Robinhood, which takes the complexity of trading stocks and simplifies the flow, allowing a wider variety of individuals to trade stocks when the markets open from anywhere. Additionally, if you're someone who's active, we have MyFitnessPal, which allows individuals to set diet or exercise goals and keep track of them through either location or Bluetooth pairing to wearable devices. And Home Depot apps shows the customers exactly where to find the product they're looking for on a specific shelf alongside a map of the store they're actively in. Also, probably the most complex mobile apps are games like Candy Crush, Pokemon Go, Angry Birds that make use of super complex technologies like artificial intelligence or augmented reality, so that you can have a much easier and addicting time-crushing candy or well, throwing some Angry Birds at pigs. And then we have Native Apps, which can also be downloaded from the respective app stores or even preloaded by manufacturers of the system. Now, these systems can be over the top like Roku, TVOS, Android TV, Fire TV, Xbox, your little brother's PlayStation, mainly like any consoles or smart TVs. But also, Native Apps can be Mac, Windows, or Linux-based as well. Usually, desktop apps are built in Electron, which is NodeJS-based, Tori, which is Rust-based, or similar frameworks. Some examples of popular OTT apps would be Netflix, Hulu, HBO Max, usually streaming media. However, if you're someone who doesn't really like to watch Netflix and chill with your friends, these options aren't only limited to video. You can also have audio apps like SoundCloud or Spotify. For desktop apps, there are plenty and likely you already use some. We have Skype, Slack, Discord, if you're a gamer, and even Visual Studio Code, all of which that I just listed are built using Electron that uses JavaScript and web languages. So, you might be asking yourself, why native and mobile apps? Well, they provide new marketing and customer acquisition channels that regular websites may not be able to. These apps will appear on app stores that have their own opportunity for store optimization in a similar concept to search engine optimization. These apps may also be the first point of entry for customers looking for your product, as well as individuals, as well as, sorry, my bad. These may be the first point of entry for customers looking for your product, and usually these customers actually go to the app stores first rather than searching on a Google engine. So, it can be the very first point of entry for users to be able to see what you have created.   So, it's important to use the features of the customer's most powerful device. And some of these features include location services. So, you can tailor the needs of the customer based on where they actively are and where they're going. This also includes payments, which allow you to leverage things like Google and Apple Pay, which are directly integrated into the device and enable a much easier payment flow. Additionally, you can provide offline capabilities so your customers can experience your services even in times without internet coverage in a much more seamless way than the web could provide. These are just some of the features that can be leveraged with native and mobile apps. Another important advantage is the easy pathways you can create to help customers complete transactions. For example, if there's a complex process such as booking an appointment or a difficult payment, you can provide them with a very streamlined flow. Unlike browsers that have many distractions with various in-web functionalities, native and mobile apps can have a much more streamlined navigation, what a spelled out user flow. All the while leveraging the features that we just mentioned to make the whole experience much more efficient and effective. So when it comes to digital product strategy, mobile apps play a large role. Not only can they be the single point of entry, they can also complement what you currently have on the web. Whenever you're thinking about building a mobile app, you should consider having some unique features in that mobile app. Things like Amy mentioned as complex purchases and designed user flows are just one way to kind of have enhanced presentation for your company. As you're going through a complex booking flow, sometimes if you're booking an appointment for a hospital visit or doctor visit, sometimes you need to have the ability to get a specific type of appointment and the user probably doesn't need to know what that actually is at the end of the day. So by providing guided questions, you can go through and create a way to dictate what journey they need to have without actually telling them what that is. Along with this, the misconception is that a website and a mobile app should be the exact same. However, users are not expecting the exact same user and user experience between those two platforms. As you use mobile apps like Android, they have a specific feel to them and iOS has a different specific feel and if you provide a user with an iOS experience on Android or vice versa, customers will end up losing trust with you because they have something that doesn't feel like what they're used to. These are very important to do and a lot of people miss that and they try to make one user experience for both platforms. However, there are experiences that you need to have for both. So apps should be a compliment to your website but not necessarily a direct clone. So how do we build apps at phase two? There are three main approaches. So there is a cross platform. So these are frameworks like React Native and Flutter. There's also native script but we don't use native script. These are a right once published everywhere for the most part. Then we have native that will be Swift for iOS and Kotlin for Android and then there's BrightScript for Roku. And then the third option is like a hybrid web in PWA. So I kind of lump these three all together. Frameworks for those are gonna be like Ionic and Cordova. Cross platforms are the most effective from a development perspective on building an app. Basically with these frameworks you can write one code base that happens to be in JavaScript and then from there it turns it down into native technologies that can be shipped to the app store. This is really important to differentiate between PWAs that can also be written in web languages but they are not shipped to the app store. Almost always with cross platform apps you have to write some native code. You're never gonna get away with writing a large enterprise app without writing some native code. A lot of these functionalities with the APIs are available by third party contributions from the communities but there's always gonna be something that you need for a specific device as you come through that can require you to go down and write that actual native code. Previous generations of React Native had issues with performance. They've since done a complete rewrite of the architecture under the hood and now you don't have to worry about the performance degradation between the two. They're coming so close that it's really hard to differentiate a true native app versus a cross platform app. One other piece that you do get with cross platform is you have access to everything that you would have on the device if you were writing a true native app. The only difference is how hard it is to get to that technology. So native apps. These are going to be written in, like I said, Swift for iOS and Apple platforms that also includes TVOS and Mac apps can all be written in Swift. That is the Apple's preferred method of development. There's Objective-C but that has been since pretty much deprecated because of the drastic difference in time to do development. Google platforms use Kotlin and Java. Again, Java is being deprecated as the not preferred language because of speed. I will mention that Kotlin can also be done as a multi-platform. So you can actually write a Kotlin app that will compile down to iOS. It is in a very, very early stage but it is possible. One concern with native apps is you must have two completely discrete teams on building these apps and they have to try to stay in sync. There are very few people that can write both Android and iOS at the same time efficiently. These people do exist, they're very expensive, they're very hard to come by. So in this process, you have to maintain both the cadence of releases for operating systems. So Android and iOS do not release operating systems at the same time. So you may have an upgrade for one and not the other and then you'll have to try to keep the feature parity as you keep going through. This is the most performant option because the APIs are direct in the languages and you don't have to write a layer of abstraction between the two. As you go through this though, the one thing is this is probably the most expensive way of building a mobile app because you have to have two discrete teams and we're talking teams of five to 10 people on each side for iOS and Android specifically. So third option, this is the hybrid and web PWA space. So I know a lot of people think PWAs are like the first thing that comes to mind when you come from web tech into a mobile app. PWAs are not the silver bullet for these because every platform behaves a little bit differently with what they support for PWAs. When you write a PWA, you are, PWA stands for Progressive Web App. When you write a PWA, you are actually just wrapping your website in a mobile browser and then saving that to the user's home screen, which is just basically a shortcut to exact same kind of technology. The only differentiator is that it has a service worker that allows you to do things like offline mode under the hood. There are lots of different platforms that can offer PWAs, so React, View, Angular, Pick a framework. There's also specific frameworks like Ionic that allow you to do this out of the box. So it is a fast way to get to market, but it is not a dedicated mobile app because you cannot put one of those in the app store. And Apple still has a bad relationship with PWAs. They are not supported as much as they are on Android. Along here, there's also the option of doing like a quote what we call a hybrid app, which is an app that's built with native technologies and then everything is web viewed in from a website. This can work, but you do end up hitting a ultimate like ceiling of what you can accomplish. Each of the web views are a subset of the native browser. So it doesn't matter which browser you use on an iPhone, it's still powered by Safari and WebKit. However, the web view, you still have a limitation of what APIs you have access to. So you may not be able to get Bluetooth or you may not be able to get hyper local precise locations without a huge layer of abstraction and big expense. And sometimes they're actually not available at all. With a traditional web app, these are things that where you write a web app and then you just ship the mobile version and then you have the user access them in a browser. These again are not ideal because you still don't have access to the same APIs that you would have with the traditional native apps. Now here is where Drupal gets mentioned for the first time. So this is our model of bring whatever you have and we'll serve it to your consumers. So at the top of this chart, you have your content or CMS. We have media, we have custom APIs and databases. So anything you have, we can work with and then bring into your mobile app. So custom APIs, things like Salesforce, NuleSoft, Epic EHRs, other custom EHR systems for electronic health records. These are all examples of things that we can consume with an application service and then serve up to your mobile app. From the application service layer in the middle, that is where we provide APIs for the apps to consume. This is our traditional decoupled architecture that you've probably seen for decoupled Drupal sites. However, we're talking about just consuming it for a mobile app. So application services serves as a way to manipulate the data in a way to get it consumable for the app. So your Drupal site can always stay the same for whatever CMS you're using. So for the actual application service, it is just a middleware between your app and for content, your media, your other APIs. What this allows us to do is normalize the data and present only what we need. So we typically leverage GraphQL to do this. The reason for this is we can specify easily exactly the data we need and we don't have to worry about over-fetching with a huge rest query. We can write a bunch of discrete queries to get exactly the pieces that we need. Another benefit of writing the application service in between is the ability to obscure sensitive API tokens. So anything that you compile into the app gets shipped to the user. So if you put an API key in your code base, it's gonna end up being shipped to the user and technically someone can decompile reverse engineer and grab your API token. By allowing us to have this application service, we allow a one-way communication to the service, to the sensitive service by running it through the application service and using a Kajido VT to pass it between the two. This allows us to prevent things like a PHI to be stored on the user's device. That's always a concern, same thing with financial data or anything, the II, personal identifier information. So by doing, even like layer in between, we're allowed to kind of separate the two worlds between the user, the client side, and then the server side where all the business logic lives. Also by putting the business logic outside of the app, it's easier, you can ship features without having to actually ship a new version of the app because you can write it in the business layer and then as long as the app knows how to consume whatever you're spitting out, you don't have to worry about that. Also in the application service, we typically have application configuration this is typically, this can be saved in either Drupal or in another system as a custom database, but the app will speak to the application service, figure out what configuration, what features it needs, and then respond to that and display that to the user. One more thing is the caching. So depending on your APIs that you have, APIs have rate limits typically, and what you can do is you can have the application service call your API for you and as long as it isn't super real-time data, like search results, like booking slots don't typically work because you have, some slot could be gone, but you have that ability to cache things in between where you are and that way you don't have to worry about hitting a rate limit on APIs. This is a common occurrence we've run into. So how does Drupal play into this now? So we've gone over what mobile apps are, gone over some architecture behind them, and while this being DrupalCon, you're probably wondering, how does Drupal actually play a role in all of this? So Drupal is more than just a content management system. It's able to handle translations, media, internationalization, and database views that help with custom queries. With these, Drupal can be implemented as a data source, either directly through Drupal's APIs or through a middleware, like an application service that we just discussed about earlier. However, directly calling Drupal as a backend source has a lot of benefits. Probably the biggest and most obvious one is that it's much easier and faster to implement than using a middleware. You would have a direct line of communication to your data source rather than needing another service or system in place. On top of that, you can leverage the skills that you already know. If you're experienced with Drupal, then using its APIs won't require as much learning when compared to figuring out a middleware application service. And Drupal's core REST API gives you multiple formats that you can use off the bat, such as XML, JSON, and Hall JSON. Drupal is flexible enough that you can store any type of key values in its database. This allows us to store configurations for runtime in Drupal and have an interface that can be modified by content editors in order to enable or disable features within the app based on what the environment requires. But we all know Drupal isn't just about its core functionalities.  So to name a few of those that would be valuable in powering mobile apps, we have GraphQL, a great contrib module that enables complete control of the GraphQL schema. It provides full support of the official GraphQL specification with all its features, including reading and writing through queries and mutations. There's also the RESTful Web Services core module that enables you to expose entities as REST resources to allow a native or mobile app to talk to a Drupal site. With following that, we have the JSON API core module, which implements the JSON API spec for the Drupal entities just mentioned. And to top it all off with another fantastic contrib module, we have DructsDrupal modules. These Dructs modules greatly simplify decoupled development, making powering mobile apps that much easier. Now we're gonna talk about a case study that we've used for phase two. So we built a large enterprise mobile app for Northwell Health. Northwell Health, if you do not know, is a very, very large hospital system in New York. There are over 70,000 employees, along with 800 hospitals and care centers in the Long Island area. As being one of the largest healthcare systems in the US, we're able to build them a app using all of the services that we talked about before. And it's been a long multi-year process to help create their digital patient experience. So the application does consume Drupal, so there is content served from Drupal, there is also content served from another CMS, sandy.io, that uses all of our configuration. Discrete teams worked on discrete pieces of this, and that's why we were not able to just use Drupal to just handle everything. But by decoupling everything, we were able to talk to different teams and not have to worry about one team owning something and then trying to integrate them together. It has a highly personalized experience and the ability to see your patient records, to schedule appointments, to find care, or providers you may or may not have seen before. Location services, messaging services to tell you like real time, like appointment reminders, text message services. This app in particular uses Gigia as our authentication provider, which is a completely custom provider that we had to integrate with native code. There is a lot of native code under the hood for Gigia. So these are all the SDKs you have to work with on a regular basis to do like complex integrations like that. From this experience, they've been able to gather, oh, sorry, yeah. So booking appointments are probably one of the biggest ones they were doing to get access to their clients or to their new patients. So there was lots and lots of iterations provided to get ways to book and make it easier for users. And that's where the custom booking flows came into place in that we needed a way for a non-developer to have a way to build a flow in order to get it into the hands of a user faster than us having to spend weeks getting into a backlog and then turning into a release. So by using configuration in a CMS, we were able to drop the time from three sprints, so six weeks to a single sprint, and that we knew right away when it needed to be done, we could spit it out and it could go live in the next two weeks. Because Northwell has so many providers, they have over 4,000 physicians in their system, they needed a robust search, so they have their own search algorithm they use that they own from scratch, and then we had to communicate with that via GraphQL on our application service in between those layers. And all of this, the way we did it was we were able to stick all the GraphQL queries in configuration so that we also, again, we could make the changes to serve up different data without having to push a new version to the app store. One consideration always is when you publish a new version, you have to make sure it's backwards compatible unless you're gonna force your user to update, and that was one thing that typically people would never wanted to do then with the force and update, so backwards compatibility is always a challenge. Another piece they added was Consolidated Bill Pay and Chatbot integrations. These allow them to collect money quickly and then have users be able to access information that they may not be able to find easily, they may be looking for something specific, they are able to add a Chatbot that allows us to help guide them in the right journey. This is another way that we've able to provide pathways into finding different places. Text stack of what Northwell uses. Drupal, of course, for Content, Apple, for the iOS support, Android for the Android support, Pigea, InterSystems, Experian for Patient Identification, Cerner for the support of the scheduling system, Taylor, which does the payments, or forms processing, HealthPay 24's payments, follow my health, is their tracker for test results, built with Azure and Docker to deploy with Node.js as the app service, React Native as the underlying application technology, and AppCenter for the build process of compiling the apps and then shipping them to the respective app stores, and then finally, Acquia for hosting of their Drupal instance. So, are you our next client partner seeking an enterprise mobile or OTT app? Agency partner looking to expand your offering to be OmniChannel or a passionate mobile app developer looking to work with the latest technologies at phase two. Find us at booth 333 to learn more about mobile app development and other new technologies that we're working on, such as Outline, as well as how we can help your next project be a success. And we have some time for questions. There's two mics, one in the middle and one over there on that side. Hey, how you doing, Daniel with MDVIP? So, thanks for the presentation, very relevant to some of the stuff that we're doing as well. Part of the challenge with GraphQL middleware that we're experiencing and the React team is not supporting blue-green deployments and on the Acquia platform and so forth. And you solve one of the problems is by storing the queries outside of the apps, which probably help a lot, which I'm gonna look into. What are some of the recommendations you can give for, I would say early development on React Native, we've recently transitioned to and we're having challenges, coordinating and not delaying the graph work because of the apps, because the business does not want to, for example, deploy builds as often, force app updates and so forth, same thing. Other than using contracts or Poly Federation and so forth. Yeah, so definitely in that case, we had basically two sets of GraphQL queries at some point that whereas version one lived there, version two lived there and that's how we ended up moving to the configuration option because we knew that we had to support back two versions. So we had like unknown cadence. In your case, you said that the business does not want to release very often. That's a challenge in itself, because you're gonna have to have the ability to try to get those updates out. But when you're thinking about it, I think the best way is sticking the queries themselves in essentially they live in a database, essentially there's a string of a giant GraphQL query. It's not ideal, but it was the only option that we found that we could support backwards compatibility because we can deploy at any time the application service and make changes there without having to go through like a formal deployment process. So I think that's probably the first thing is start thinking that way of what can I offload to essentially like a database where I can have a key value pair and then bringing it back and then having your Apollo on the client side, do we go be like, hey, I got that app configuration at the beginning of the app. But when we initialize the app, you get the app config.  One more question. Yeah. There's nobody else. Go ahead. So doing progressively decoupled Drupal applications, we're doing React.js on the front end, hitting GraphQL, also doing twig with hitting GraphQL in some cases, right? And how do I put this? How do you standardize to make sure the developers are naming the queries consistently because the fact of GraphQL, you can name your own methods, your own queries, right? It becomes a big disconnect and using Apollo Graph Manager, which is a great tool, then you get like different consumers calling the same thing differently, right? Incorrectly in many times. So have you experienced that and how do you solve it? I mean, this is the classic problem of naming things as hard, right? I think the biggest thing is communication between your teams that when you're, if you're gonna go make a new query or modify a query, go look at Apollo, figure out, go look in your GraphQL playground, figure out what's already there and what's not. In our case, we had one team that was managing all of the GraphQL, so it wasn't a huge deal, but they were also the biggest consumer of it, so that was why they were the ones who owned that piece of it. But other departments were also calling it, but it was just one piece that was in charge of the entire graph. Got us. You don't have like a guidelines documentation or anything like that. Yeah, like typical guidelines for like, here's how you name things, right? And we had like, here's how you name classes, here's how you name functional components, et cetera. So we just have like a general guideline of here's how you name things, but enforcing that is nearly impossible, I determined. So again, it's that naming problem, typical programming, naming things as hard. And then you're using JWT for authentication, right between the system you said. So having the JWT exposed in the network on the client side, it's not a security issue at whatsoever. No, cause you need the other half of it, right? So JWT isn't a big deal. You need the private key to match it. Yep, I understand. Okay, so never came across any compliant issues. Okay, thanks. All right, thank you. Hello. Yep, hey, so I just wanted to share, I just wanted to share an approach we've been using. It was pretty interesting. We have like an e-commerce application website that's the kind of point where I'm trying to say websites and application. React Native Web, super awesome, saved us a ton of time, saved our development team a ton of time, complicated checkout and just building that, using React Native Web. React Native Web allows you to like basically take a React Native application. They do it kind of what you might consider backwards, which is not, cause it's mobile first. It'll take like the React Native code and then output HTML, which is awesome because we would change something like super complicated checkout logic and then we would have to, like you said, the two different teams and now with React Native Web, we basically have one team where we combined our teams now cross functional and working across the board. So I just wanted to share that with everybody. It's pretty cool way. We've done something similar in that we basically ripped all of the logic out of the, like it was a React app. We ripped all the logic out of all the components and then we stored that as like a shared piece. So then everything that was like presentational was either written by React or React Native. It worked out well.  But once you had like that layer in between, you were able to just go ahead and write either a React or a React Native. And then when we did the compile process, it knew like which components to grab. Yeah, and we did that with the mono. We did that in the beginning and using NPM and everything was hard.  You make a change in the shared folder and everything just updates and you can kind of see it in the simulator and everything, so. No, definitely a good approach. It's a pretty cool workflows, yeah. Yeah, we should talk more about that, though. Hey, Greg, hey, Amy. I was just, yeah, there's no other real people who have questions. So, other.  Actually, cardboard cutout, two dimensional. Don't look at this side. But other than going against a Sicilian when death is on the line, what are some of the classic blunders in your opinion that people make with us and they should not do? All right, the one thing is trying to force an Android experience onto iOS or an iOS experience onto Android. I think that's the biggest one. Yeah, like if you just immediately assume PWAs are the only way to go and just straight up copy it to the mobile experience, you're gonna have a very bad time. Especially the users are gonna have a bad time trying to figure out how the app works. It's because they're not used to having the browser on their phone. They're used to an app for their flow. Yeah, and I think kind of dovetailing to that is the trying to do the hybrid approach where you're just webframing in a bunch of things. Like there is a place and time to use a web view for certain features. Your entire app is not the feature. Definitely you hit a ceiling of what you can actually accomplish and then you kind of have to be like, well, now what? Because if you didn't invest in the technology to actually do some native work in between, you're gonna end up having to basically start over. Another thing is if you are just gonna webframe in a bunch of things, at least do the effort to remove the header in the footer because you really don't need that in the mobile app because you already have a navigation system. Because what's gonna happen is you will end up like getting off into some random place in your website and never hear how you got back to where you started from. And especially you have to do link management because some links, if you just have just Ahrefs in your web app, they will just take you out of the app into some random website and the user might not even have a way to get back, which we've seen happen sometimes and it's terrible. I'm Ujwal from et cetera. So I have a question for transition data. How do you manage that transition data and the caching management at the React or GraphQL? Any challenge or? All right, so let's start with the translation piece. Basically, whenever we make the calls to whichever, if it's REST or a GraphQL, we typically just pass in the language as a parameter in there so we're able to get it that way. And then you mentioned caching. In that case, caching's hard, right? It's the same concept. What we end up typically doing is managing the cache on the application service. And then if we have to flush it, it's only in one place, but we know that that is the single source of truth. So we need to make sure you determine where your source of truth is because if you have multiple layers that can be cached, so if you have a Drupal site that also has a couple of caches, you can also run into problems of having stale data. So just make sure you, if you're gonna flush the cache of the application service, know that you're gonna get whatever's in the Drupal cache at that moment, not necessarily whenever you go and update that site. So I think that's kind of the biggest one. Also, setting appropriate length time on your caches is also very important because some things can live forever. Some things need to be updated pretty frequently. You can also do things where you check to make sure what needs to be, like when the last time it was cached, you can do some polling. We've also used subscriptions to update data that way as well in GraphQL. Obviously that's not supported by the Drupal module at the moment, but real-time data in Drupal is not typically something that we see. If you're gonna do something real-time, you don't want anything cached in that layer. My name is Paul. I have a question about offline stuff and I'm curious if you've done that at all and if you have any experience using a PWA versus native and if one is easier. Yes, Amy made me able to talk about this one a little bit more than me, but definitely we've done it. In the offline mode, with native, you're able to store much more information into like a stink storage on the devices and it allows you to persist it way longer. So you can persist hours, essentially permanently, in the ability to cache things that way. When you run into a PWA, you don't have control over the cache as much. So with native, I can say, okay, dump the cache. With a PWA, you're at the mercy of what the browser does. So if your phone decides that it's full and it wants to dump the cache, it could dump the cache at any moment. Yeah, and for iOS specifically, they have a separate PWA container for storage. iOS has 500 megabytes for their storage and you don't have any control over when you can dump it. I think deleting the app might actually clear the storage but it's not like the documentation is not clear at all, it had to control it. And then the async storage or local storage on the web that you access on the mobile app is very regular. It does not go into that same container. It goes who knows where and it can reset itself when it wants. It's much harder to control when it comes to a PWA. For Android, I don't think the issue is as big but it's just there are a lot of restrictions that are out of the developer's control when it comes to PWA's. Sorry I'm back. We have this one weird edge case. Just wanted to see if you could experience it. With React Native WebView on Android, when we're signing out of our IDP because we're limited with our horrible IDP, that's no API based, we have to use the browser. For some reason, Android's WebView handles it different than iOS and we're losing the connection so we have to force the user to close the browser to re-initiate. Is this something you've run across? Cause it just sounds like a weird Android bug but. It is a weird Android bug for sure. I haven't run into it. I had the unfortunate experience of having to write a SAML setup like both sides in node because it doesn't exist anywhere. So similar concept like where we ran into the problem of Android does have that issue of it loses the connection. iOS is definitely better handling the handoff between the two. But yeah, there's definitely that weird bug. Like we've run into a lot of strange behaviors between the two platforms. And that handoff with the WebView is definitely one of them. The only option is switch providers. I mean, that's not a real answer. I understand. Well, at least you helped me save the time and not wasting more time and figuring out an alternate solution. Yeah, there's no alternate solution other than like. Close the browser. Or figure out if that method is public, which I don't think it is. Cause I think we tried the same thing. It's protected, yeah. So get on the phone with Google. I mean, if you have connections, a lot of apps have a Google partner that can help you. Sure. Maybe it's a try to be like, hey, this is not working. Let's see if we can figure out how to get it to work. All right, so don't use Salesforce IDP check. Yeah. We have five minutes. Any more questions, anybody? We don't have any questions and thank you all for coming. I'm just glad to have you all. Please visit us at booth 333. If you have any questions that may come up after you leave or if you wanna learn more about phase two and what we do.