Dive Deeper with RHB: Custom Portal Elements

Yep, perfect.

Hello everyone that is joining.

See people coming in. Go ahead and say hello up beating me to it. Go ahead and say hello in the chat.

Going to give a couple minutes here for everybody to join. Usually it's a slow trickle.

We've got around 200 people. Yep, yeah, OK, I'll give it another minute or two.

I'm seeing a lot of names I recognize.

You get to see his face rather than a slack icon that's funny.

Hope I see Teresa. Hi Teresa.

You're not near usual seat.

I still see people trickling in.

But let me go ahead and get started. We'll go ahead and get through these initial slides here. Welcome everybody. Thank you all for coming today to this late stage days is diving deeper, with RHB on custom portal elements.

And it will be with your presenters John Rowland and John Michael Kucha and I'm Stephen Bates. I'm client support engineer here over in the Portland office. Here technicians I'll be the moderator today. We're going to have a great session as we can see here. John Round here is from teachers College, Columbia University and John Michael. Here is with RBS, a senior technology consultant there and from the chat I can see that a lot of you are already familiar with John Michael. So let me go ahead and jump through some of the quick housekeeping.

Things I'm sure if you joined any of the other slate stages you seen this before, but this is being recorded. It'll be made available to you if you have a festival pass that's in your home slate, which when you log into slate, if you hover over the your picture in the upper right hand corner, it'll be like the middle option there to jump into home slate. If you need close captioning, you can click the CC button up there in the upper right. Likewise, if you want to expand and view in full screen, just click the expanding arrows up there. If for any reason there's any audio or video desync, please just refresh the window. That should take care of it.

And for any questions you have, just post them in the chat. We'll address them and I'll go ahead and turn it over to John Michael.

Thanks so much Steven.

Hi everybody, good to have you here today. You may notice my my colleague John our colleague John hasn't quite joined us just yet. He and his wife just yesterday welcomed a new member of their family brand new baby and they're on their way home from the hospital. He jumped into our rehearsal session for this yesterday from the hospital and it was mind-blowing. How committed he is. That being said, the first part of the presentation belonged to him and I'm going to roll with it so John will jump in and join us here shortly.

We might backtrack on just a few slides to get some additional context from him, since his the first part of what he has to present tease up maybe more of the technical and tactical things that I have in the the second part of the presentation. Today's presentation custom portal elements is really a case study in a portal experience that we had our HP collectively built with John and the team at Teachers College as a successor portal to their previous experience that they had.

Few fast facts about teachers college Columbia. It's in New York City and it's the United States oldest, largest and most comprehensive school of education. They've got about 10 departments, 250 study program combinations that are encapsulated within the school and within their instance of slate. They launched Slate in fall of 2014, so coming up on the eight year mark of their instance, one of the more seasoned instances out there, relatively speaking.

Quick introduction about us at RB.

Let's see here.

He is a higher education consultancy that has guided hundreds of institutions toward greater relevance and ultimately success in achieving enrollment, retention and revenue goals for over 3 decades.

We deliver expertise across 4 practices that you see here. Enrollment management, institutional Marketing, Executive Council, and slate and related technologies. We have a footprint in more than 10% of all slate databases and we offer best in class implementations, diagnostics, advanced builds, and training. While I have a little bit of perhaps a national stage, I'd also just like to briefly tell you about decades use and outside of RHB. I'm also a senior program director for Domestic Enrichment Center of Texas.

A nonprofit located in Houston, where I've been involved for almost 25 years where I live.

Established in 1994, decades is a three week summer academic enrichment program for gifted and talented students. In 3rd through 6th grade. Our mission there is to provide a qualitatively differentiated learning experience developing young leaders to use their gifts for the betterment of the world around them. We're one of a few. A growing number of organizations that use slate with a primary or elementary school audience at Dukatz Slate is not only our enrollment management.

An advancement platform. We also use it as our SSIS and our ERP and Slate succeeded our homegrown platform in 2019.

When Teachers College brought us on board, here was kind of the state of the world with respect to their existing status page and their admitted student portal, they receive about 10,000 ish submitted applications and have about 333 hundred admitted students. They were using the delivered out of the box application status page. The standard status portal, which probably predates a little bit of terminology.

You're not even the generation. The first generation of the standard status portal with the portal editor that we have now. Even before that they use the old teaser system and excess Lt Portal style system. So if you've been if you're an OG slate person and you know those words you know we're winding the clock way back here in terms of where teachers was were when they came to our HP.

They had a lot of things that were motivating them. They really wanted to catch up with newer generation tools and evolve the experience to be something that they hadn't even imagined before. Something even better than what it could be with these older slate tools that have mostly since been been sunset or that many institutions have migrated off of. This probably looks pretty familiar and John might be able to tell us a little bit more once he jumps on. This is the standard status page that they had.

It may look very similar to things that you've seen before. May look similar to your own portal.

Caveat, there's no judgment here. Your portal is your portal. Your experience is your experience. There's not saying that this is better than someone elses or better than anything out there, but they had also what you see John circled in the green up here in the corner. This was the experience that from the status page.

They had this icon where a student had to jump into what they considered their admitted student portal experience.

Inside of that.

A very kind of first generation ish experience with respect to how their portal even worked.

25 methods with 25 queries with an XSLT file with more than 3000 lines of code.

This is where you used to have to live. If you were an OG slate user, this is how the first generation of these tools came about.

And John has probably a story behind a couple of these next slides. Here's one he sent that he said a portal for them that started as magic.

Quickly turned into a race for survival. He may have a story to tell us about why he chose those particular slides as his motivation, but the sentiment here is very true with those early generation tools, XSLT portals, and the standard status page, the experience in the business process is that teachers evolved to where.

The portal wasn't keeping up with business needs and the experience that they were trying to create for their audience and for their students.

This was the progress approach that teachers adopted when they joined with us to.

Rebuild and reimagine this experience.

The most important thing is that it started off with this goal. This step of goal identification.

To create some definition and plan around what is it that we want to do? What is it that we want to achieve here and a moment you're going to see one of the core tenets that we really believe about portals is that you're not building a portal. You're building an experience, and so you have to define what you want that experience to be. What is it supposed to be like? What are our goals? What are our objectives? What do we need to achieve? I'll talk more about that in just a moment. The remainder.

Architects out outlines out how we went about how we orchestrated this. There's a design process. All of the portals that we deliver at our HB are fully custom design. They're not templates, they're not anything that any other institution has. You cannot lift one and then drop one on to another. It's completely custom, but a design process that takes into consideration the institutions identity system and branding system to make it maybe match their institution website, or make it a totally different visual identity experience talking about the content to make available.

If I click back just really quickly and we look at teachers previous admit portal and you can see down the left sidebar. All of these areas of static content that they had to provide. I'm thinking back to when I taught high school journalism and I would tell students like this is a wall of text. This page is too Gray. We got to figure out something that makes this page less Gray. We got to introduce secondary content. We got to introduce other pieces of information for people to digest what they need. We need to make it more accessible. So a real focus on the content.

Came in front of what we might more considerably consider the actual process steps of portal building, which is build the thing. Test it and launch it.

All too often we start to reach for the tools before we start to consider what we want this experience to be, and we need to take that beat. We need to think about what do we want this experience to be and then what are the tools that help us get there? And are they the right ones to even help us create the experience that we're after? These were some other local context considerations that teachers encountered that if you're considering the same type of project that you might also take away and encounter internally, or even different flavors, different facets or versions of these.

Which stakeholders do you need to consult?

Is this something that strictly an admission office can make an advancement office? Can make a student success office can make? Are there different layers to that or they're going to be approvals?

People that need to buy in people that need to kind of see to believe in order to trust what's being built, what's being architected? What are the portal adjacent areas in slate that need changing? We encounter this very often in the projects that we undertake is that you can't just sit down and build a portal when you're wanting to redesign and recreate the experience that often begs the question, OK, well, what else needs to be changed? If you're interested in building an enrollment checklist, one of the specific examples that we're going to talk about today. Well, that begs things like.

The checklist items themselves. The rules that drive those checklist items forms that you have populating on the form checklist, and any rules that are contained within those forms.

Teachers also had, if I remember correctly, and John can weigh in when he gets here. I think they had totally undergone.

New branding and an entirely new identity system as well. So what they had publicly on their current website was even changing at the same time. So as far as stakeholders and portal adjacent things, there was even overlap in there because there were places like groups like institutional marketing and communications that had roles to speak into. What's the new identity system of teachers college and how does that play into the visual aspects of this experience? And then some of the harder questions like?

What things on the list are really standalone projects of themselves?

What are the things that have to be achieved before we can move into the space, create this portal and launch it? And what are things that like we wanna get there, but that's too big. A bite of the apple to take right now and it really stands alone as its own project. I do distinctly remember this from the teachers project with their financial aid decision letters. They have what I imagine many of us have worked with before. A field structure system.

In Slate, because this was the only way to do it, you know financial aid award, one award amount, one award date, one award status 1.

Iterate outfields for two and three and four, if I remember correctly. I think teachers had has or had 16 sets of those fields. There are more modern approaches for that insulate. Same thing could be said of scholarships and lots of other places, and slate where there's modules and methodology like entities that can replace some of those more manual things that we've done before. So speaking into the pieces that John had in these slides about how just needing to get on board with newer generation tools, because there is a.

More compatible, a newer, more widely supported way to orchestrate that in the administrative area of slate. This was a prime example of something, though that teachers said this is too big and this movement with financial aid letters just has to wait so you have to be prepared to make some tough decisions when you map out what's the totality of this experience going to be and which things might be whole projects of themselves, which of them have to be kind of drawn forward and staged at the beginning before you can get?

To the later work that is the more kind of whizbang, maybe external facing.

Pieces of the portal, so he asks. He prompts us with this great question.

What are we in the position to change?

This is really core to their thinking and to their process, and I think in just a few minutes he'll be joining on it and we'll be able to revisit just a couple of these briefly.

Guiding principles that the teacher's team used and have as advice for you. Portal builds are a process.

It's not something that you can just chop off the shelf and grab perhaps a little bit of a caveat. There you can jump into Slate showcase. Of course you can provision a showcase admission instance, a showcase advancement, and student success instances. There are briefcase table models in there that you can move back and forth between environments and inspiration that you can gather. And yes, there's lots of kind of plug and play opportunities in there for some of the things that you'll see in the moment. They aren't things that we can necessarily just reach for off the shelf.

As I said earlier, you're not just building a portal, you're not just building a thing and then The thing is done.

You're building an experience and you're trying to put that student hat on, and the student glasses on for a while and walk that path, and then maybe put on the admission Officer hat and the admission officer glasses and walk a mile in their shoes and think through that piece of the experience. And parents and schools and other adjacent offices in the university. It's not just about tactically getting to the end point of getting a new portal because we want a new portal and we want to do all these great things.

Stop and consider what do you want the experience to be, because that is ultimately what you're crafting here, and that's really what you're going to see driven home when we get into the visual and tactical examples here. Slates, tools are of course important.

But crafting and refining up front is really crucial to this process. Sometimes you have really clear thinking straight away, like, oh, I'm going to use this, and I'm going to use that. And I'm going to use rules and checklists, and I'm going to use snippets and all kinds of cool stuff, but you don't want to overcomplicate the world unnecessarily. You've got to be really strategic, really selective about the tools that you use to make sure you're picking the right ones for the right purpose. Ones that have longevity, ones that are going to have long shelf life, and that.

Are of course actively supported. Remember one of teachers driving forces behind embarking upon this project was to move to more modern tools. Some of you out there in the audience that I saw at the very beginning saw you posted in the chat.

If I've worked with you directly before, you know that I'm pretty good at admonishing you about if you have things that are like local and slate template library query bases, you should be thinking about configurable joins land and moving there sooner than later. So selecting the right tools to make that future facing investment or really is really important and not all of the ready made tools deliver the same experience.

And one thing that I really love about the work that we got to do here and a lot of the work that we get to do in general is that we kind of get to be deliberately stubborn and just say we're not going to settle for using the stock checklist part or the stock decisions part or the stock. Whatever fill in the blank widget, those are great. Again, no judgment. There are lots of excellent portals out there that use standard status page or use a baseline custom portal where you drag and drop widgets in from the panel. Nothing wrong with that. It's totally great if it doesn't match.

The experience that you're trying to deliver then guiding principle here. Don't settle for it. Be stubborn about it.

Decide what you want that experience to be and craft around it.

The example that we have to dive into here with teachers college that I'm going to talk to you a little bit more technically about now is this notion of customized checklists. Teachers College had.

And admitted student portal that was really good despite it being text really good about listing contextually. For the student, the information that they needed to know for the next things that they needed to do.

That was an important piece of the experience that we took to the table to say, how can we create this in such a way that students can visually and easily understand what they need to do? How does it mesh up with the tools that are available in Slate and where do we need to know the rules in order to break the rules kind of thing?

A customized checklist was the appropriate solution here, because there were limits with the standard checklist widget. There are some design limitations. There's some responsiveness limitations, they were just different things that they encountered. That said, OK, you know the existing checklist part is great, but there's more that we would like to do.

We'd like to actually customize the statuses that display.

Rather than just have awaiting, received and waived as choices.

We'd like to continue to find a way to provide that contextual information based upon an item and its status, so you kind of see that's what John has boxed here in green. That little icon. We'll talk more about that technically in just a minute clicking that icon as an example would give you a little modal with the information that you see right below additional information about how to activate that Gmail account. What were the next steps?

There's a lot going on here in this image that's not part of the off the shelf tool. There are also pieces contained in here that kind of go beyond the conversation today, but another piece of the experience was not wanting to have lots of separate checklists, not wanting to have a forms checklist and payments checklists, and an enrollment checklist and freds checklists. Whatever it might be wanting to have one one checklist to rule them all and a custom approach is what gets us there. What got us there.

Now we're crossing over into the slides that I've developed in, so I'm gonna be a little bit more familiar with the content, but we're looking forward to having John here and join us in just a moment, and we're doing good on time as well.

Here are the ingredients. Here are the things that we brought to the table with respect to customized checklists. We're going to talk a little bit more. Slate Hat slate captain. Any type of hat with the pieces that we included.

Of course there are checklist items themselves can't get around that. We're still using standard checklist items in the database tool.

With some special added pieces rules to drive this checklist, items and their statuses still need rules. Still need definitions on the checklist items to decide you know what? How does this checklist item get fulfilled? How does it move from one status to the other? I haven't asterisk here because I want to make the note that teachers also had.

As a kind of incoming already predefined preset thing.

They already had a data bridge system between Slate and their SIS to store information in fields about.

Now stored data that drove checklist so they had fields that were storing as the student activated their email account in the university system. Has this student turned in this health document? Because all of that didn't happen in Slate. Their instance of slate was not the hub for all of those enrollment processes, but it was the hub for the student to know. Have they done all the things that they need to do?

They already had a data bridge process between Slate and their SIS that was relaying all kinds of like yes, no flags or in, you know, other information back to the record into fields that could be used to drive the checklist that you saw in the previous slide, and that we're going to see again. So don't worry, you'll get another another crack in having to look at it inside the portal. There's a query to drive the checklist. We'll talk more about that. We use content blocks if you hear me, say snippets, snippets or content blocks and content blocks or snippets, so I'm using those words.

Interchangeably, but the formal current terminology is is a content block, but snippet if you've been around in slate for a few years, and then of course on Portal side to visually represent it, we've got some liquid markup going on, and then of course beautiful design around it as well. I'm going to open up each of these components and just kind of fly through them so you can see high level. What are all the pieces at stake? How do we bring all these ingredients to the table and cook something up like this?

We'll start with checklists and rules.

The checklist items themselves. They are straight up regular old checklist items, nothing special about them except.

A lower part of the item that's kind of below the scroll below the fold you Scroll down on a checklist site and you'll see this little XML configuration section.

This is where you can define custom statuses for a checklist item.

So you'll see the example we have here, their university network ID. They called it an uni. It had these four different statuses. These four different status states.

That rules.

Determined which status the item should be set at based upon the existence of all kinds of things and data that was coming from the SIS.

The screenshot at the bottom, the act of the one that's headed with the action label is the bottom action section of a rule. When you configure these custom checklist statuses, they then become choices in the rules editor for that item.

So you can build a rule that's got filters and logic and all kinds of stuff and set a checklist item to a custom status that you've defined on the item. The QR code on this screen goes to an article that has information about how to configure those custom statuses. Yeah, there's a nice little screenshot here. That kind of gives you the disk that QR code, by the way, is going to take you to an article that's actually headed financial aid checklist or something like that in the body of that article, there is a whole section that describes how to set up the XML.

What you see on the screen right here and what the icon mean? You know what the the icon variable means in there and what the PKV stuff is. Guide you through all those steps.

These don't need to be predefined anywhere else, they're not prompts.

They're not fields, they're not anything else special. It's all strictly right there in that XML config box, and that QR code will give you more info on that.

So we make our checklist items. We define all these custom statuses.

We set up rules to define how those statuses should be applied.

Pro tip, when you set up rules for these items, make sure you use exclusivity groups to your advantage.

Make sure you use them in such a way that avoids too much unnecessary processing amongst those groups, so practice good rule architecture number one, but exclusivity group architecture #2.

OK.

Important things to take away for that.

With the query and content blocks OK inside of the portal editor.

We have to define we have to create a query to return a list of all those checklist items for a student. OK, the result set the query is going to give us one checklist item.

One row per checklist item, right when you build this, when you go into the portal editor and you hit, you know new query to add a new one. You're picking from the related type list and the base of checklists and that will give you 1 result row per checklist item. There's some additional things that have to be added into the filters area to filter down just for the checklist items for that student. For those of you who are super advanced out there, yes there is a way a newer way to do this with a dictionary export. I'm not digging into that necessarily today, but inside of this query.

That is one row per checklist item for a student.

We need all the exports that we want to display in the custom checklist.

Or that we might leverage to build inside of liquid markup. Here I've got a screenshot of a particular one where.

We're concatenating together the subject of the I'm pointing at the screen like you guys can see, what I'm pointing out. Sorry you've got the checklist subject. We're concatenating the checklist subject with the checklist status.

You're going to see some output from this in just a moment. That will make that have a visual example and kind of have some more teeth to it, but in particular we've got this one export that's a concatenation, a combination of the checklist items subject and its status, so that when the query runs, we get both of those kind of put together in one single column, one single export that we can leverage for our snippets that are coming up. Our content blocks that are coming up in the next slide. Again, this query is going to return one row per checklist item, so to display these in the portal, the query needs something special.

It's called a node.

That QR code will take you to a slate TV video and I think at about the 14 minute mark, it's cataloged in that article. It will talk about the details of what is a node. Where do I set this? Why do I set this? What this is even do? I'm going to show you what that is and just a few moments. But if you want to take a little bit more reflective time, deeper dive on. What is a node that QR code will take you there and you can get more information about that for each checklist item. Remember, teachers wanted to provide contextual information. You saw it as a little icon at the end of the checklist row.

To do that?

This is where we employed snippets to deliver that content.

Snippets or content blocks. Content blocks or snippet for giving an advance. If I use the first generation terminology, the content block library is where there's one entry per checklist item per status, so see on the left side. This is the more tactical list of the combination of a checklist item.

And a status.

So that with that query we take that combination of a checklist item and its status and run it through this snippet library to determine what's the contextual information we're supposed to provide. So for FAFSA awaiting at the very bottom that FAFSA awaiting snippet has the text.

That we want to contextually display to the student when they're chicosci item is set that way when it's FAFSA complete, we can change up the content and have something else displayed.

So up to this point, we've got checklist items with custom statuses.

We've got rules to keep those items current.

You need a portal query that gives you a list of all the checklist items that a student has.

And we've got these customized content blocks for all the contextual information that we're going to provide based upon the combination of what that checklist item is and the status that it currently has.

There's nothing special about the configuration of the snippet itself on the right side. That screenshot is from one of the Gmail activations 1. There's nothing special. There's no secret hidden codes in the source code or anything right there? What you see right there on screen is exactly what's in that snippet. Just text, no special anything inside of it.

The last two ingredients on the table were liquid markup and design, so the phonetel ingredients to bring. There are things like HTML with CSS and liquid markup to create that visual rendering. That table we're going to see it again.

This uses a concept that's called liquid looping.

Remember, different students are going to have different numbers of checklist items and different things on their checklists, and rather than having to build on the back end and the portal editor some massive long code bit that takes into consideration all of the different permutations and combinations that there could be. This liquid loop lets us define just one row of the table.

That acts like a template that's going to then iterate out for each one of the checklist items that a student has.

In line 174 specifically.

This is the start of that loop. This is the start of that iteration and the part that says Enmr underline checklist.

That's a node, so when you're watching this later on and you're going well, where's the node? Where do I use that in the portal, and how does that connect back with the query when you're looking at that Slate TV video and taking the deeper dive on how to assign the node on that query?

Here's where it is in this example so that you know how it's used. Later on, it's used inside at the start of this for loop to define and set up the framework for how we're going to iterate out one row per checklist item.

In this customized checklist element.

So E&R underlying checklist. That's the node later on when you're reviewing this line 178.

Just go straight to the end.

There's the status, the merge field for the status of the checklist item.

Awaiting received whatever the custom status is that we've defined for that. It's just simply a merge field that's coming from that query that are the result list of what the checklist items are for that particular student, and then on 183 there's a merge field for the subject.

So so far.

We're really setting up very similar framework to what the stock part does off the shelf. Everything we've talked about up to this point so far is more or less what happens when you go in the portal editor and you grab checklist by section and you drop it in there. All these things are happening behind the scenes. The portal already knows to be context aware for a particular student to just serve up their checklists and you have some front facing pieces inside of that widget Configurator to set some things right there on the spot.

This is kind of a lot of what's happening behind the scenes by virtue of dragging and dropping in that widget, but now we're making our own. We're creating our own instead.

Also on is 183. Yeah and 183. You'll see towards the end you'll see the image tag where we're just calling it an image for that little informational icon. The thing that the students click on to get more context about the info. So that's part of our loop as well, because we need one of those included with every item.

You're going to see some other merge fields here. There's some that I'm skipping over. I'm glossing over specifically some that are in pieces of style code. I've talked about this in a few other presentations, and I think in my slate stage presentation last year as well, where you can use items from those of you out there who are designers and heavy query builders, use pieces of your queries inside of your style code.

So based upon whether something is awaiting or received or waived, use that as a declaration in your CSS to drive style code and then run a merge field right here like you see on one line 177 to use information about that item in the style code itself. We're using it here to do some things like change up colors and icons and labels with respect to whether an item is received or awaiting or incomplete or otherwise received. That I mentioned, all waived.

The QR code here.

Takes you in for this deeper dive on liquid looping.

I'm going to go back one slide. Don't panic, so from 174 all the way down to 187, that's our loop.

We're telling Slate do this thing.

For every record that's in.

The query that it returns.

Assigned to that node. So if I have 10 checklist items, run this loop 10 times. If I have 5 checklist items, run this loop 5 times. I don't have to tell it how many times it's just going to run it until it runs it once per result row in that query. This QR code takes you to an article about liquid markup looping where you can really take a deep dive on OK. What are all the nuts and bolts that are at work here? How do I take this information in and then, you know, build this, build this from scratch and replicate some of what you've seen in the images beforehand.

The result is what you see here. So when we actually execute this and there was a lot of the style code and other cosmetics and things like that design work that I didn't have as part of the screen shot.

But for this particular student, 123456789 ten 11 checklist items on this enrollment checklist for the student different statuses, some of them, say, receive some of them, say activated. Some are awaiting, they got green and a checkmark red, and an X. All of that is employing dynamic information about that specific row that specific item, the transcript items have the name of the school very similar to the stock part, but we had to construct it to work that way. Each rose got that little informational icon at the end. I'm going to talk more about that on the next slide.

But that QR code will take you to an article for liquid markup looping to really study up on how does this work. How do I take a query and iterate out this table without having to build out a row for each one? Want to give a shout out to our HB's front end designer and developer Melissa Chambers. She's just remarkably incredible at a lot of our front facing development and design work. As I mentioned at the beginning, none of our No2 portals that we create are exactly alike.

They're not template. There's no copy pasting going on, everything is just start from blank. All the design work is completely customized and you can see here in the teachers example we've of course got a lot of their identity system represented and created. The experience that we wanted with that they wanted respect to the the colors and the icons and the headings and the type sizes and the backgrounds and alternating rows, colors and stuff like that.

The last part in here to show you I haven't talked about the contextual information and how we got how we're getting the icons at the end to kind of do their thing.

Here it is.

There's a second loop in all of this.

We ran the loop once. I'll click back, we ran the loop once.

To set up the table.

Of all the checklist items.

We're going to run it again.

And in this particular loop, what we're setting up is a pop-up or a modal that has all of that contextual information. And here is where the rubber hits the road with the example or with the information I gave you early on about combining the checklist item and its status together.

Mine 201.

We're taking that special export that we made right there on the fly, and the query where we combine those two things together. The name of the checklist item and its status.

And we run it through the snippet library. We say take in that information and return us back the content that you're supposed to get. Here's how that looked and the content block editor here was every item along with every possible status it could have. And inside of each one of these is the contextual information.

So when you set up your liquid markup in this fashion, the name of the export with the pipe delimiter and this is all documented as well in the knowledge base snippet and the name of the snippet library. The Content block library.

It grabs the data that it receives from that export.

Zips it through this library to find its option, find its match, and then returns the content.

That is assigned in the snippet.

Every single item with every single possible status has to be defined in here.

That's the only way it's going to return content. You can see up at the top towards the top of the screen shot where it says default no default exports have been configured. We didn't want any content returned by default. If it didn't find anything in this list because we wanted to be exhaustive and make sure every single possible checklist item with its different statuses was represented in this list, because each one of these and depending upon their status could have different information that they wanted to provide to the student. So in this example here, line 201 is really the.

Big piece to tell you about today, of course. It's surrounded again by beautiful CSS code that our front end designers and developers have written and created over time where we're creating models and pop-ups as part of our custom work. So the end result when you click on one of those.

Little icons, those little informational icons at the end of the row is an on screen pop up that just kind of light boxes itself right on top to give the student that additional information. So this screenshot is from clicking on about FAFSA, waiting FAFSA, and here's the dynamic information because it said FAFSA was not complete.

There are two articles in the knowledge base that really dig into this notion of content blocks and snippets. This QR code is going to take you to one that immediately has a link at the top of it into another article. So I kind of started you backwards with this QR code, but intentionally because this first one has got a link to a second one that I wanted to be sure that that you had. So if you start reading the article that's at this cut that that's at this specific QR code first and you're like, oh, this is a little high.

This is it. Went up real quickly. There's another link at the top of that article that takes you to one that you might want to read first. Just as a starting point.

Each experience we work with with our clients is fully custom. We bring to life fully custom design and again that line 201 with the snippet.

Key is how we draw in that content.

Because we have time.

Bonus content everybody likes bonus content.

We do the same when it comes to the decision update module.

We don't just drag and drop the status update widget in nothing wrong, no judgement if you're doing it rock and roll.

The same principle applies here, so this is the decision widget from the teachers College status Portal. It is not just a drag and drop and restyling of the existing widget. This is built with the same principles. There's a query that returns a students decisions along with. Is it a correspondence letter or is it a decision letter? Has it been received by the student? Has it not been received by the student?

And we display it in this.

In this in teachers instance, the actual visual representation is these little tiles. These little cards that are really nice that take them onward to the same old decision letter, the same one that is built in the letter templates area.

But we can also do some fun things with styling to show them. Have they opened it? Have they not opened it?

And also show them how many this is another piece of the experience that teachers wanted to.

Try to resolve and I've heard I've heard this as I experienced it myself at my previous institution. How many of you out there having students who read the admit letter and then they don't read the other letters they don't see scholarship? They don't see financial aid award. It's just not quite the experience that you want. Remember what I said about and be stubborn? Be stubborn.

Build a better tool, build a better way to do it.

In this particular orchestration with teachers, if I were this student logging in, I would see, oh, I have four things. I have a decision letter and I have 3 correspondence letters. I don't really get a clue as to what they are. I'm not giving away a surprise necessarily to the student straight away, but I can click in, read my decision letter and if I come back here, not seeing that there's more stuff for me to read. Oh well, my portal dashboard reminds me I've got more letters to read. Here are the ones that I haven't opened just yet.

More bonus content.

Same song, different verse, but look through the events lenses. This is another section of the TC portal.

The first three.

Going from left to right, so May 19th and May 20th May 23rd. Those are delivered in this same fashion. There's an event based query looking for events in the future.

Maybe with some other specific criteria and orchestrating a loop to return information about those events, not only what is the name, what's the date? What's the time but the description from the event?

The link to register for the event.

Very dynamic and when May 19th what's today when today is over.

That May 19th event is going to fall out of the criteria of the query, and when the student goes back on May 20th No May 19th event has gone the 20th. 1 scoots over the 23rd, 1 scoots over. And now maybe there's a May 24th event that is populated by the query. I called out the first three specifically because I know the last one is just static, it's not populated by a query because the experience that we had here was three of them needed to be dynamic query based events and the last one was a static one that they were just going in and managing on the back.

Of the portal.

That's a quick flyby quick dive into how we took this experience to the next level at Teachers College.

Like we did have a few questions that came in beforehand and maybe some that have kind of flown by in the chat that might be specific as well. I'm going to go back to this slide here with the two of us. You're welcome to reach out to myself at RB. John doesn't have an email on here, but you are absolutely welcome to find him on LinkedIn. Jump in there and search for John Rowland and he would be happy to connect with you there and start to correspond with you.

I made it, I made it.

And Steven, did we have questions that we wanted to take or other pieces of our? Oh there he is Papa, how are you?

I'm doing great, yeah.

Congratulations, I told the world. I hope that was OK, sorry if not.

Yeah, thank you so much. Yeah, and thanks for taking my part. I came right at the last slide too. You sounded great and I appreciate you putting you on the spot there for that.

No he didn't.

Yeah.

You bet you. I hope I lived up. You'll have to watch the recording and tell me if I lived up to the promise. I think we did it justice and you know, did the presentation. Thank you for your work. But congratulations, glad to have you here for the last minute. If you would like to revisit any of your slides briefly here or talk about anything, feel free and then I think Steven is still with us as well. Can help us negotiate.

Questions to you.

Yeah no, no, I just wanted to add that I expect you did an awesome job. Just that to reiterate the process. I know you touched on this, but I mean, that's really what we was awesome with working with. RHB is just not taking that portal right off the shelf like going through all the steps making sure it was tested.

Early before we launch and it really made the user experience for the students so smooth because we didn't have much to to fix. And so yeah, if I ever get a chance I will fight for a chance to work with you again on the part also.

Fantastic, I did not see. I think we only the only question I've seen is from Jennifer right now. That said, can you share some of the back end HTML for the bonus decision letter break out?

Ooh, uhm, I don't have a working screen shot here to show you at the moment I'm going to pull the slide that is.

Maybe this guy right here, so this is the checklist 1 the principle is the same in terms of.

Sorry, I'm on a laptop today, so.

You're going to have no, not that one. You're going to have. You're gonna have a. You're gonna have a query in your portal that is this is related type, but decision based one row per decision. That could be a bonafide capital D decision. Or it might be a correspondence letter as well, same principle.

That query is going to need a node.

Because you're going to need to know how to address it in a liquid loop like this, so this orchestration of the visual content is achieved in the exactly the same way. There's some other stuff in particular with the design. This is using flexbox to kind of flex and dynamically determine what the widths of these different things should be. Depending upon do I have 4:00 do I have three? Do I have two? And do I jump to a new row? All that kind of stuff, but the principles are the same. It's a for loop with a different node name and we orchestrate.

About OK, what is it that we want to do in this loop? Same very similar principle, just different query that's serving up different data, and likewise links that go onward to the appropriate letter. So each one of these tiles.

Does not go to the general update area. It goes specifically to that letter. All that information can be served up by that query and then orchestrated in the same way as you see right here.

Great, and I I apologize. Kate actually did ask this question earlier. Let's see it actually has two was the letter widget also built using a for loop connecting to a specific query?

Yeah, this guy right here.

Same thing.

And then for setting up the table with the loop.

Sorry.

Yeah specific yeah sorry Steven, yeah just specific query but separate query again, it's a it was a decision based query, one row per decision.

Ah.

Great and then for setting up the table with the loop, would it be better to use a dictionary export? Are there pros cons to using a dictionary for looping versus using separate merge fields?

Yeah, so the world has changed since we did this work and.

I did mention I did make mention of that earlier on that there there is potentially a newer way to look at doing this. It should work just fine using a dictionary export, so if you are used to if you're familiar with doing that, and if I'm speaking a language and using words that you understand, yes, instead of having a wholly separate query, you could use dictionary X words, but only because since we developed this with teachers and now the current version of Slate supports.

Liquid looping with dictionary exports in portals. Did I string together enough slate terminology right there that if that was a lot between, you know you could not do that before, but now you can. You can liquid loop through the output of a dictionary, export in a portal. You can do it and deliver. You couldn't do it in a portal. Now you can do it in a portal. Haven't tried it myself, at least in a live example that we have here right now, I would expect it to work. I've done it tons of times and other little utility portals so.

You should be able to orchestrate the same thing and not have to do a wholly separate query if you understand that dictionary concept.

Great and then Alex had a question. He said he's interested in what you were using for the checklist image SRC. Can you clarify what you were using for the merge field? See list under score item dot status under score image specifically.

Yeah.

Where are you?

Yeah, I think those were designed by Alyssa if I remember correctly, yeah.

Right, yeah, yeah, you're right, John.

Who you're?

Yeah.

Oh, thank you, sorry yeah, you're right. John, thank you.

Yeah.

Yeah, so here in line 183 that actually spans kind of two lines in my screenshot. So we're the image tag starts you see source equals portal status portal image info dot SVG so that little tiny eye bubble at the end is just an SVG image. It could be a PNG, it could be JPEG. It could be Fred, could be whatever you want, but that's the image. It's the same for everybody, but dynamically. We're changing with these data tags this micro modal.

Trigger where dynamically changing when when you click on a particular one. How does it know which pop up to generate this part at the top? This in 174. This is going to be definitely contained in that liquid looping article, so I told you that. ENR underline checklist is the name of the node. The Liquid loop article goes into this. This prefix that you use as part of setting up the for loop that you then use to address.

Each of the items that you see, like in 177 and 178. So for each of the things in the enrollment checklist query, we want to serve out.

All of these different merge fields inside of a for loop. You have to prefix these merge fields.

With what you establish at the front of this for loop, I couldn't just like in line.

Line 178 at the end where it says see list under score item dot status. The name of the export in my query is just status. I can't call it that way though because it's referenced inside of a for loop, so specifically in the for loop I have to put the prefix.

That we establish at 174 at the front of the name of the merge field you'll see this referenced in that liquid looping knowledge based article and.

That would be the place I'd send you just to kind of take a deep dive on what are all the technicalities of what we're setting up in line 174? It's not a specific thing that we designed, it's very well documented and used in lots of places and throughout site.

Great.

Looks like Emily said, uh, plus one to the person earlier in Chad who asked about the XML configuration on Slate standard checklist items like transcripts.

I think that was from you. Michael Montgomery. Yeah, can the XML configuration be used in system based system based slate checklist items such as transcript?

Yeah.

Good question, haven't tried it, don't throw.

No.

Nothing.

Can't couldn't tell you definitively. I tell you. Try and test environment go go shove it in there and then the test environment. See what happens. See what you see. What you get. We didn't do that here because it didn't. It didn't rise to that level of the what teachers needed, where they needed anything other than the standard items for transcripts and stuff like that. But also as you mentioned, as the person who asked the question mentioned, they were their system ones. They weren't custom ones like what we're seeing here with the uni, so we didn't try. But that's not to say that it can't be done.

Yeah.

So be stubborn about it and go. Go experiment and see what you get.

Oh yeah, yeah.

What I'll add there though, is what what you did succeed in, which was a huge game changer for us was on the application view. It would still show received, received copy as green like it does as the slate delivered checklist. But then on the admitted side, using formulas on the subquery export, we were able to make the received copy look like awaiting because we when they're admitted, we need their official transcript. So that was pretty cool.

Good yeah, thanks John. I had I had forgotten about that this was and that's another thing that the dragging and dropping the stock part off the shelf is not customizable. And now that you say that, I do remember that we had that here. Where in the representation that the student got in there. You know the checklist that they saw in their portal. We didn't want it to say received copy. We teachers wanted it to say awaiting and showed the red X even though administratively internally this late it may have had that received copy status, they were still tracking it that way internally, but the portal.

Was interpreting that status as. Oh I should show a waiting there and instead so it just provided lots of surgically precise opportunities to change up that experience and make it make it work the way that you needed it to work.

It looks like Jamie's question was answered by John in the chat, so Steve asked, where would you like to go from here with regard to the portal? What are the future enhancements you're thinking about, if any?

Yeah, hey Steve, good to see you in here.

We only got 4 more minutes, huh? I'll definitely reach out to you.

And Slack, and we'll catch up. I think you going to summit. We'll have to catch up there too, but just a few off the top of my head of like there are a lot of contextual TC related ones. We're looking to do so. Like for events, they were those ones that John Michael had mentioned that were queried so that it would show up and drop off the way they were set up in the folders was basically one off by the program. But then we realized later that sometimes programs will join together to do combined events, and so we'll just need to rethink how we'll do the folder.

To get those to display because they still need their individual events and then they want their group events, and so that's going to be a fun, fun build. Yeah, what else? I'm just looking here.

Ohh, advising and registration contacts and so right now we only have brought in the admissions counselors and financial aid counselors. And so we're going to go another level deeper for for. For other staff that we want to feed in. And so that'll be a multi section build. So those are just some examples. I'll definitely go through my notes and and and catch up with you.

And anybody else is welcome to reach out to me and ask to. I'm more than happy to to share.

Great quick quick last question. Just piggybacking on Alex's earlier question, he was asking how is the path pulled in the query itself specifically.

Path of.

His The Let's see that was about the image. See list under score item status under score image specifically.

Dude.

Here.

The path for the image itself is just hardcoded in. There's nothing dynamic about it if that's what you're asking, it's just uploaded.

This is uploaded in.

The deliver library. The image library.

And so it's inside of T's instance, just as an image file, like most of all of the image files that are referenced in the portal. But here it's specifically just an image that has been uploaded into their instance to customize and used.

And the item.

They're saying line 178.

OK.

178 sorry, I'm leaning in. I'm getting super close. Sorry folks. Lean back from your screens.

That's like it's slate for ants right now on my screen. Line 178.

Ohh, what are we doing there? Yeah that is.

This first image, that's the check of the X.

So there's a different export in the checklist query that's deciding what image do I serve up based upon the status that it has. And this is kind of related to what John mentioned a moment ago. Some of the statuses they wanted to redefine on the student facing part of the experience but not internally inside of slate. So that line 178 is just the the check mark images and the X images. There's not a I should have taken a screen shot.

Of the waved version, but the waved version was a grayed out it's a Gray check mark and it says waived and Gray text so that part that you see reference. That's this first image was. We're just specific icons that we loaded and used because they matched TCC's identity system versus the ones that are built into slate which didn't match the visual identity system and the high fidelity design stuff that we used in the overall.

Branding of the portal.

That's what that is.

OK, all right we are out of time unfortunately, but if you do have additional questions please, that's right, Miss John Michael said earlier. Please feel free to reach out via email via Slack, LinkedIn, any any of your preferred social media. Thank you so much, John and John Michael for your time today. We all really appreciate it. And thank you everybody else for coming.

Yeah, thanks.

Take care everybody.

We will see you all hopefully at Summit.