RX 24 - Becoming a Lego Master - Using the Bricks in Creative Ways - Stan Yoder

Transcribed Content

Article, and the author says, if you made it this far, congratulations. This is the last session of the day. You made it this far. Good job. I'm really looking forward to what Stan has for us. So let's give a warm welcome to Stan Yoder. He's gonna talk to us about becoming a LEGO master using the bricks in creative ways. So if you're at all like me, it wasn't too long after you started working with Rock when you figured out how truly flexible it can be, and what a large variety of features and tools it has. And for me, this was very quickly followed by the question, how do I figure out which feature or tool to even use? In this session, we'll take a look at a bunch of these features and tools, what I like to think of as LEGO bricks, and talk about how I approach deciding which ones I use for my projects or builds. Then we'll revert back to elementary school and have a little show and tell of some of the projects from the crossing. And hopefully, these might inspire you as you work on solutions for your church. But first, let me tell you a little bit about myself. I graduated from college with degrees in mathematics and computer science. For the first ten years of my career, I worked as a programmer analyst and systems architect, primarily in the glamorous field of employee benefits management. Fun fact, this is also when I was given the name Stanalyst, which you've probably seen in Rocket Chat. I was part of the base development group, which designed, developed, maintained a custom application platform called Total Benefits Administration, or TBA. Our client support teams would then adapt this platform for the needs of our external clients. Sound familiar? It should. I was making the LEGO bricks, kind of like what Spark and Triumph do with rock. Then in 02/2004, I followed God's call into full time ministry when I moved into the field of church technical production. First, I served as a technical director for a few years, then I became a systems engineer where I was responsible for system design, integration, maintenance, etcetera. Basically, putting together various components and processes into systems to support the needs of ministry. Then three years ago, through some very strange or really god circumstances, I ended up moving from the production team to the rock team at the crossing in St. Louis. So I've also I've really kind of gone full circle. I started out making LEGO bricks, and now I'm on the other side and I get to play with the bricks and build some cool stuff. But I guess that's appropriate since I'm really just a big kid that never liked or never lost his love of the brick. Okay. That's cool. I like to play with LEGO. But what in the world does this have to do with rock? Glad you asked. First, let's consider how I approach playing with LEGO. And then we'll talk about how I apply that when I'm designing and developing in rock. Whenever I got a new set of LEGO, first I'd looked at the box to see what things it was designed to build. Then I dump out all the pieces, look through them, see if there was any I hadn't seen before, and maybe try to figure out how it might be used. Then I grabbed the build instructions or the manual. I'd start following the steps to use the bricks as they were designed and intended to be used to create whatever vehicle or building or gadget for was for that set. I know, I was one of those weird kids. I like to follow the instructions. But then I'd start putting a couple sets together to make something bigger and better. You know, and LEGO even included some inspirations for this with their sets. And then there was the motor. Boy, I loved the motor. That's when things really started to move. Hey, I'm a dad. I'm a license to tell the jokes. I know that's a grunner. Eventually, I started finding ways to use the bricks in creative in ways they weren't necessarily intended to be used. But I had nothing on what some of these folks figured out to do with LEGO. Hey, this is a rock conference. It's not Toy Con. We're supposed to be learning about rock stuff, not LEGO. You're absolutely right. Thanks for teeing up the transition for me. So I approach playing with rock in a similar way as I did with LEGO. When I have a new project or request, the first thing I do is figure out the requirements. Who's the audience? Is it for staff or non staff? Members, regular attenders, visitors, guests? How tech savvy are they? Who are the stakeholders? Is there even a stakeholder? Is there a clear scope for the request? What is the life cycle for the data, the process, etcetera? How long does the process take? Where should things be stored? Do we even need to store anything and for how long? Are our storage needs something that's person centric or not person centric? Are there any requirements for tracking or reporting? Basically, what am I building? Next, you need to know your bricks. As I said earlier, Rock has a huge variety of features and tools available. The more you learn about each of these and how they were intended to be used, the better you will be able to put put them together as part of your builds. As an added bonus, getting to know your bricks also helps you to start to discover how they can be used in more advanced and creative ways. As you can see, this is a pretty long list of bricks to choose from. And you know this isn't nearly everything. I think I heard it's 600. I mean, I forget, it's huge of blocks and things. But these here are all ones that I've used in some form or fashion as solution at the crossing. So I'm going take a minute to go through some of them, but we don't even have time to get through all of these. But I want to start by thinking about that question, what are our storage options for person centric versus non person centric data? Since Rock is a relationship management system, it makes sense there are a variety of ways to store person centric data. Each of these has their own pros and cons. Person attributes are great for storing basic data that relates to a large section of your folks, But it's really not so great if you're only targeting specific segments of your population or if your project has lots and lots of attributes and data. And it does have some history, but I've always been a little challenged to use it well. Groups and group members are really good for data that is related to specific segments of your folks. But we did discover a limitation here, given that a given individual can only be in a group one time for a role. And this burned us when we were trying to gather some new small group information from our group leaders about the groups they were going to be leading. And we quickly discovered some of our people actually lead more than one group. Connection requests are primarily designed to take somebody from signing up to serve through a series of steps and processes to placement in a serving team or a group. But you know, they really can be used for so much more, especially when they're paired with workflows. But there are already a lot of recipes in past Rx presentations that show great examples of this. Steps are primarily designed to track a person's progress through a series of activities and accomplishments, or steps, that lead to a desired accomplishment or goal. And we do use them this way for some things. We've also found they're really good for storing other person centric data that doesn't even always lead to a final goal. And they have a great ability to store historical snapshots of person related data. And there are other bricks which are person centric, but these are the four big ones on my list that come up a lot. What about when your need isn't person centric? What are the options then? To be frank, they're a little more limited. Global attributes and defined types, while useful, should not be used to store lots of data and are really more for static data like settings or parameters, not for gathering information from folks. Maybe you're asking why I include content channels here since they're primarily used for driving content on web pages, But that doesn't mean they couldn't be used to store data, especially since there's a great workflow action content channel item add, which helps in saving the data to the content channel. And speaking of workflows, I know you might be asking, why would I include them here for data storage? Especially if you have watched this video from the Triumph Architecture series where John talks about proper workflow form, he specifically cautioned against using workflows for data storage and to really think of them more as the muscles and not the structure. And I agree this is absolutely true for most scenarios. But during our show and tell in a bit, I'll talk about why in some very specific situations it could make sense to use your workflows to store your data. By the way, if you haven't watched that video, you should. I highly recommend it. Okay. So what do you do if none of these bricks work for your non person centric data? Great question. And I'm happy to say there's a great answer. Don't forget the plug ins, especially the project management plug in from Blue Box Moon. And this plugin is great for managing projects, but a huge tip, it's also really flexible and can be used for storing other data that has nothing to do with projects. And while we're on the topics of plugins, here are the few of my favorites that I rely on regularly. I'll point out just the first two here for workflows. If you want to take them to the next level, these two really help, especially if you're like me and you think like a coder. Each of these have more features than the ones I listed here. But these are some of my favorites. Bottom line, when you're not finding what you need in Rock Core, excuse me. Bottom line, when you're not finding what you need in Rock Core, be sure to consider the plug ins. So let's go back to the core features and look just at a few more. We did talk about options for data storage, But what about settings and parameters? And we started here a little bit with group attributes and define types. Let's think about a specific scenario. Let's say you have a form where you want to have the user pick from a list of ministry areas. And you want the workflow to then email the appropriate ministry contact based on what they choose. You could just set up a single select or a multi select for the ministry area attributes on that form and have a LavaRun action that is hard coded with the ministry contact for each area. But now, any time a contact changes, you have to edit the workflow. Ugh. What if instead you used a defined type for the ministry area and you added in an attribute that points to the contact person or group? Now your workflow's lava run action can look up the contact based on the user selection instead of being hard coded. And changing the setting doesn't require editing your workflow. And a little bonus tip with this, if you'll use the cache lava filter when you grab the defined type or value, you don't incur a read from the database. Okay, so what about reporting and dashboards? First that come to mind are data views and reports. And these are great, but sometimes they don't quite fit the bill. When this happens, I reach for one of my favorite brick combos, pairing a page parameter filter block with either a dynamic data block or an HTML block. Together, these provide a quick and simple way to create dashboards of info for your staff that offer more customized functionality than data views and reports alone. Okay, we didn't get through them all. Wish we had time for that. But I really encourage you to get to know your bricks. Then you can start to use them creatively. So now that we've talked about my nerdy way of playing with LEGO and how I apply that in my approach to rock, it's time for some show and tell. We'll start with a simple one. So let me give you a little background first. Explorations is our six week class where folks can explore their faith and ask the questions they thought they couldn't ask in church. During the first few weeks, the leaders and teachers of the class encouraged folks to submit their BSQs or big scary questions. And then on week five, a panel of pastors and leaders answered those questions. Early on, when the class was newer and we didn't have as many sessions or as many campuses, we just gathered these questions via paper into a box, literally a physical box in the classroom. Later, we started having people send in emails with their questions. But both of these became very tough to administer as we had more and more campuses and more and more sessions offered. So the requirements for our project is we needed the ability to gather these questions electronically. And we really wanted to do it at any time, not just during class. Each question needed to include who submitted it and which session they were on or which campus they were at. And we needed to provide a means for all the teachers to see the questions and demographics. So we had to consider a few things. We had two audiences, the folks attending the class and the folks leading the class. While we could have considered this person centric data, since it is a person submitting the question, we were going to be taking multiple questions from each person. So it really is more question centric data. So we didn't really want to go with person attributes or groups or anything that was tied to person. But we also didn't want a lot of overhead because it's not going to stick around forever. It's just for when that class is. So what did we do? Well, we already knew we're going to be using a workflow to get the question from the user. But and we did set this up so that they could access it from both a class portal page or from our web app. And here's that point. Remember earlier I said you shouldn't normally use workflow to store data? This is actually one of those exceptions where it does make sense. We don't need it for very long. And to be able to ask multiple questions, we actually put that as an attribute of the activity. And then the workflow could just recursively start that activity over and over until they told us they were done submitting questions. And then we, of course, need to get those back out to show to the teacher. So for our dashboard, we went with one of my favorite brick combos, which is the page parameter filter block paired with a dynamic data block. The page parameter filter block allowed the user or the teacher to filter into a date range. And the dynamic data block filters could be used to limit it down to specific sessions or classes, since oftentimes these were running at the same time and overlapped. The SQL query for the dynamic data block looked for workflow instances in the selected date range of the workflow type. It pulled the person and group from the workflow attributes, but it pulled the questions from the activity instances since that's where we stored the question. All right, here's another example using the same combo with a little twist. In this case, our youth team wanted a better way to manage their camps and retreats. They already had all the registrations and group placements figured out. But after that, managing all the things wasn't so straightforward. For summer camp, for instance, they had 13 different registrations for our campuses and leaders and boys versus girls. Plus, all the info they needed wasn't in one place. It was spread out between the registration, the registrant, the registrar, and the group attributes. Plus, as another thing they wanted, they didn't want to send if a parent had multiple kids that were attending camp, they did not want to send one communication for each kid. They wanted one communication for the parent that listed all their kids. So it wasn't really a lot to consider with this one. We just have one audience. It's the youth, staff, and leaders. So there's nothing to store. We just need to know where to pull the data from. As I already said, we went with my favorite combo, the page parameter filter block paired with the dynamic data block. But we did step it up a bit. We wanted them to be able to reuse the same page for each event without having to rebuild the page. So for the first filter, we let them choose from the group they want to view. And it might make sense to use a group picker, but we wanted to make it a little more user friendly. So instead, we used a single select and used a Lava entity command so that we could customize a list to just those groups that applied for camps and youth events. Then the second filter was a multi select that used some SQL to get all the related registrations based on the group they had picked in the first filter. And this allowed them to filter down to students versus leaders or for specific grades and genders or sorry, campuses and genders, not grades. For the dynamic data block, it does take a bit of SQL to pull all the things together. But if you look close, it's really just the same pattern repeated over and over for each new attribute we needed on the report. And then we talked about being able to send the parents one email. And that we use the advanced settings for the Dynamic Data Block, and specifically these two fields, the communication merge fields and the communication recipient fields. This is the magic for allowing us to send that one communication to the parent, but still include all the details for the student. So while they may be on the dynamic data list multiple times, once for each of their students, when you go over to the communication from there, they only appear once. But in order to access the student, then you need to use this lava in your communication. But we didn't just give them this. We also wanted to have them have a way to get to print out the various rosters they needed using merge templates because they didn't always have access to rock at camp. Plus, they needed to be able to share this to camp personnel who didn't have access at all. We did use another plugin to accomplish this, the PDF Toolkit. This allowed us to use Lava to generate formatted PDF files for them to print out. Woah, that was a lot. Probably a little bit more detail than we can cover this class, but don't worry, it's in the takeaways. So let's take a look at some of the sample output from this instead. Here's an example of the room rosters. And we included t shirt information. And that code that buzzed the screen a little bit ago, that's actually what created these room rosters. And I'm only showing you a couple of them. But for each room, we would include the name of the student, their grade, and what t shirt size. And then we were able to use Lava to total it up per page and then have a master shirt count at the end, which helped them with distribution of shirts. Here are a couple more. The left one's a bus roster, And we did page breaks at each bus as it changed. And the one on the right is actually the report that was given to the Kent Medical personnel that included their information. All right, let's look at another example. This one uses a project management plugin, but not for project management. And we use the workflow Stimpak. So the background, we host an annual one day event called One Future STL, where folks from churches in the St. Louis area gather to pursue unity, celebrate each other, hear from a variety of voices, and spark conversation. We also invite area organizations to set up booths for folks to learn about who they are and how they serve the St. Louis area. Our leaders wanted a way to encourage attenders to visit the booths by entering them in a giveaway based on the booths they visited. They were inspired by last year's booth promo from RX. So our requirements we need a way for event attenders to log their attendance at each booth. We need a way for the leaders to know who attended which booth. And ideally, we don't want to require adding those attenders to our Rock instance because most of them don't attend the crossing. And they didn't really want to have to install anything on their phones. So bottom line, they wanted us to keep it simple, lightweight, and accessible. No challenges there, right? So what do we consider? Well, we have two audiences, the event attenders and the event leaders. And again, this seems to be person centric, but they don't want us to store a person profile on Rock. So we can't really do that. We need to have a list of the booths and organizations. We need a mechanism for the attenders to check-in at the booth, but using check-in is out. But hey, the good news is we don't need the data to stick around very long. And we did actually consider a couple of third party solutions for event and conference management. They were all a tad pricey. And we couldn't go with the rock solution because, again, we don't have people, and we didn't want to install anything on their phones. So in the end, we went with a printed QR code for each booth. And that took them to a URL with a unique identifier for that booth. And when that was scanned, it opened up a web page with a workflow entry block. And the workflow would look for a cookie on their device to determine if we'd seen them before. And then we also knew which booth they were, so we could track that and then give them some information about who they just visited. But I want to go just a tad deeper in this solution. To manage all the boosts and the QR codes, we set up a new defined type with a couple of attributes. That way, we could use the GUID of the defined type as that key that was stored in the URL of the QR code, which got passed to the workflow. And then we also included the website of the organization and description, and that way the workflow could provide that back on the confirmation screen. So the Rock team didn't have to be involved in setting everything up. We set up a separate admin page so that they could manage this specific defined type, and it let them put the entries in themselves. And then because they were going to have a lot of QR codes to manage, we included a custom column on that block that automatically would generate the QR code with the appropriate key for each booth. By the way, do something like this for your short links. It's a really fast way to take your short links and quickly generate QR codes for your folks. To track everything, we used a project management plugin. So we set up a new project type for the Boot Tracker. And the attender was a project, not a person. We could store that project identifier on the cookie. That's how we knew we'd seen them before. Would, if we hadn't seen them, we'd ask for a little bit of information, their first name, their last name, and their mobile number. And that would get stored in the project as attributes. And then a couple other things about which boosts they'd visited in the visit count. For the dashboard, we did use the plugins project list block. But we did put it on its own page because we didn't need all the functions of the project. We just needed a few things. So we used some CSS to hide the things we didn't need. So that was the structure for this one. And then for the we talked about the workflow or the motor. Here's the workflow logic of that. And again, it's in the takeaway, so you don't have to take a picture. But we did use the workflow stimpack. And the two specific actions we used were the activate activity with attributes and the set entity attributes. And these weren't absolutely necessary, but they do make it a lot easier to set up in code. And just so you get an idea of what the user experience was like, the left image shows what they would see if we didn't find that cookie and we didn't know who they were. The middle image then would show when they did a booth visit. Again, we're giving them back the booth they visited, information about that organization and the website. And then the last one showing the list of all the ones they visit, and they could open and close those. And there's a little indicator next to the ones that they visited. Okay. So far, the examples have been kind of simple combinations of bricks. We're going to take a quick look at one that uses a lot more bricks. So let me give you a little background. Our serving profile is kind of think of it like a membership application. It's a tool which helps our pastors get to know the attender and assess where they are on their spiritual journey as that person is moving into a role of responsibility on one of our ministry teams. We often ask folks to complete these every few years as they continue to grow or when they transition roles. Our current solution had been to use person attributes to store all the different questions from the profile. While there were some things that we liked about it, it also had a lot of limitations and challenges. So when it came time to redesign it, we had a pretty long list of requirements. And we will look at these in more details in a second. First, I wanted to show you all the bricks that went into this one. We won't go over them all, but I'll call out a few. We talked about steps earlier, and here's an example of where we're using steps that don't lead to an end goal. But it does allow us to store that historical snapshot of the profiles as they submitted throughout the years. And then by using entity attributes and categories, we can keep those nicely organized on the profile in that step. The motors for this, the workflow we actually had several. We had one workflow that allowed staff to request a person to complete a profile. Then there's the workflow that actually lets the person complete the profile. And then we had another one that allowed pastors to enter their review notes or comments as they looked through profiles. And finally, this is more administrative. We had one that actually took our legacy profiles from the person attributes and generated PDFs so we could keep that historical record. So I want to talk now about how we address some of the requirements of the project and look at specifically some of the bricks we used. And maybe this will inspire you for your projects. So let's look at tracking the requester and the automated notification process. We just said that we had a workflow that would run when they requested a person to fill out a profile. So that made it easy to track that. We just kept track of who ran that on the profile. But that whole thing about automating who gets notified based on their selection was a little trickier. The old way, all the profiles got emailed into one person, and she had a literal Excel spreadsheet that she had to look through and determine who, based on campus and ministry, she had to contact. And sometimes it wasn't always very clear. So we didn't want to embed all that logic into the workflow itself. So you kind of got a preview of earlier. We went with the defined type that was the ministry areas, that that's what they would select on the workflow form. And then we added in the group as an attribute on the defined type that would point to a group. And then within the group, we actually had campuses so that we could indicate which campuses each person got notified for, because some staff members covered multiple campuses and some only did one campus. So that gave us the flexibility to match that original Excel spreadsheet. And then finally, we used the workflow, the Lava Run action, to kind of dynamically build all that based on what they selected. The other piece we wanted to figure out, which we had in our original design, was we allowed the person, because it's a larger volume of data that we're asking for, so that to work on it and save it as a draft and come back later. And typically for a workflow, you start it and submit it in a single session, especially if it's one that's from the external website. To allow the users to save the draft, we had to tie a couple of things together. Okay, thank you. On the landing page for the serving profile, it includes logic to look for an existing serving profile or step of the person, consider the status for the most recent one. And then it builds the link to the workflow based on what it found. The key was we saved the GUID of the workflow, if they had saved it as a draft to the step so that we could send them back to that same workflow and leave it open until they were done. And so what that looks like for the user is when they come to the landing page, this is the message they get if they had been requested to fill one out. And then they're taken into the workflow. And we even had a little status page that will allow them to complete the different sections of the profile in any order they wanted. Here's an example of one of those. They could work on it or cancel and go back and step through the sessions. When they go back after they fill out a session, it would have a check mark to say it's done. And then we used some JavaScript to hide the Submit button until all four sections were completed. If they click Save for Later, we confirmed it and then took them back to the page where we would say, hey, you've got one in progress. And that would let them go back into that same workflow because we didn't close it out. Finally, let's take a really quick look at these last three. This is how the pastors can review them. Kind of think of them like a dashboard. We could have used because we were using steps, we could have used these built in step blocks, but they didn't quite meet our needs. So instead, we created our own page under the person profile with several HTML blocks, a dynamic data block, and a notes block. One HTML block was the menu that let you choose from the different profiles they've submitted. The other HTML block displayed the selected one, but it would only display it based on whether they submitted or not and who was allowed to see what. And then the notes block was the different comments that pastors had submitted. There you can see the full profile. And then because this was sensitive data, we wanted a way to kind of know who'd been viewing profiles. And so we tied in a dynamic data block. And originally, this was driven by the page view interactions. But we determined that we could do it better and have a little more customization by using the Lava filter interaction right. And I want to make sure we have time for Q and A, so I'm going to skip my last example. So it took longer than I scripted. Anybody have questions?