Kate: All right. Hello and welcome to PodRocket. I'm Kate, the producer of PodRocket. With me hosting today is no. Hi, Nole. How's it going? Noel: Good. Good. Thanks, Kate. Kate: Thanks for joining us today. And our guest today is Kathryn Grayson Nantz? Kathryn Grayson Nanz: Nantz, nailed it. Kate: We were just talking about this right before the recording, so then I like... Kathryn Grayson Nanz: That makes it worse somehow. It brings on that panic. Kate: Right. Katherine Grayson Nantz. Thanks for joining us. Katherine is the Developer Advocate at Kendo UI working on KendoReact. Katherine, thanks for joining us. Kathryn Grayson Nanz: Yeah, absolutely. Thanks for having me. Kate: So just to get started, can you just tell us a little about yourself and your role and what you're working on? Kathryn Grayson Nanz: Yeah. So as you mentioned, I am currently the developer advocate for KendoReact. I've had one of those weird wandering career paths where I started actually in design. That's what I went to school for and then meandered my way over into development and then UI design and development. So component libraries were the best of both worlds. As soon as I found that, that felt like I had found my niche and I'd had a couple jobs working for companies to help them create component libraries. When I was reached out to by folks at Progress who were like, "Hey, we build this component library. You want to come maybe talk about it with us?" And I did. It was great. Noel: Nice, nice. Yeah. I feel like that's an interesting journey. I guess it's probably somewhat common to have people with design backgrounds working on component libraries, but do you find that that design background lends itself particularly well to dev advocacy? That role specifically? Kathryn Grayson Nanz: It's been really interesting. I think in some ways it really has just because it's a little bit different than some of the other dev roles. And design for whatever reason is having a moment now, which seems really silly to say about design, which is something that has been in existence for as long as humans have been in existence like painting on cave walls. But design is having a moment in tech right now with component libraries and design systems. And we're seeing a lot of these new ways to categorize and manage the designer-developer handoff. And so it's been really cool to have the design background and be able to participate in that and bring a different perspective, I guess. Noel: Yeah. Nice, nice. I want to get into that designer-developer handoff a little bit later, because I notice you've done some recent writing and speaking and stuff about that in particular, but maybe to just step back and frame this a little bit. Can we just talk about what Kendo is, Kendo UI just lay groundwork for people coming in fresh? Kathryn Grayson Nanz: Totally. Kendo UI is a family of component libraries. We have a library for, at least for Kendo UI we have JavaScript libraries for React, for Angular, for Vue, and for [Jay Gray 00:00:03:32]. Took me a minute there because I am super focused on the React library, KendoReact, obviously. So we have a whole bunch of components, well over 100 at this point and, really, our main goal is to write the components that are hard to write, that suck to write so that you don't have to write them. Big things. Data grids and color pickers, schedulers, Gantt charts, stuff that if you've ever had to sit down a right one, it makes you want to tear your hair out a little bit. Noel: Yeah, totally, totally. Yeah. Yeah. I feel like there's that's the common problem. Do you guys find most of the users for Kendo UI are people with existing apps that are trying to just go in it and abstract this low-level stuff? Or is it people building that new... Or is it a mix of both? Kathryn Grayson Nanz: Mostly we get people with existing apps. Part of that just has to do with where we've positioned ourselves. We are a paid library. So we tend to have more clients that are at the enterprise level. We're open to anything and we will happily talk to you about a license and you can try it out for free, but a paid library's just a little bit different and it isn't necessarily the solution for everyone. However, especially for teams, big teams that have big apps, we can really fill and fix a pain point in trying to roll all of that yourself from scratch. Noel: Yeah, totally. That's an interesting point. So going with one of these libraries more focused on larger orgs with big existing apps, what is the pro there of going with something like Kendo versus one of the open competitors, the component libraries that are just out there able to be pulled? Kathryn Grayson Nanz: There are a bunch of really good open-source, free component libraries out there. So it's a very, very fair question, but really what we focus on is differentiating in terms of support and what you can expect. So anytime you are adding a dependency to your app, you take on a certain level of risk, right? There's a risk that the library might be abandoned, that it's not maintained as often as you like, that bugs aren't fixed as quickly as you that, that whatever problem you are having isn't necessarily high priority to the maintainers of the library. Kathryn Grayson Nanz: But when you pay for a solution, those are the things that we can offer you. Support always within 24 hours, we have three major scheduled releases every year. You pay once, you use it forever. You get to have an input on the roadmap. We immediately address bugs you bring up. So it's really just a question of how much risk you are willing and able to take on in your application, and that answer is going to be different for everyone. Depending on who you are, your team size, what you're building, revenue. Yeah. Noel: Yeah. Got you. Got you. Yeah. Do you guys help with the integration piece? Say you have a big customer that comes on and they've got a bunch of existing web apps or properties or whatever, and they're like, "We're using..." They have 19 different table components and 27 different buttons. Is that something you guys do or do you just have the component library and sell the license and [crosstalk 00:07:05]? Kathryn Grayson Nanz: We have a support team. So we're totally happy to be hands-on helping you through any difficulties that you might have. We won't necessarily come in and swap everything out for you, but we're there to answer questions and give you direct hands-on support in a case-by-case basis so you can tell us exactly what's happening in your app and we can talk you through it. Noel: Got you. Got you. So what does that process look like? Either, I guess, regardless of if you guys are guiding the user through it or not. Say users have an existing app in there switching to Kendo, I guess we could say it's a React app for the sake of our discussion here, what does that process usually look like? Again, if it's self-guided or if you guys are helping them along. Kathryn Grayson Nanz: Yeah. So at some point, once you have either finished your 30-day trial or you've decided that we're the answer you'll get a license key, and then Kendo can be downloaded via NPM packages and updated that way so it fits right into your normal dev flow. The only addition is that you have a validation key that you have to incorporate. You can do that in a variety of different ways. If it's a private project, you can just put that in there as a text file. You can use the GitHub secrets kind of thing if you're sharing it. Kathryn Grayson Nanz: But once you've got that key set up, that's just what checks to make sure all of your components run. And then you just import into your file whichever... Our library is broken down so that you don't have to import the whole thing if you just want to use a couple of components. A lot of people will use us for some of those really big components that I mentioned before like the pivot grid, our data grid, scheduler. So if you are really just looking to have our super-powerful data grid, you can just import the data grid and then place it like any other component. It works just like everything else you'd use, which is... It's pretty handy. Noel: Yeah. Nice. Nice. Do you find people, when they're going through this, do they tend to do it pretty piecemeal like that for a while or forever? Or are people going all in and end up building essentially the whole app using Kendo components? Kathryn Grayson Nanz: It really depends. And we wanted to offer that flexibility because there's... I think one of the things that we're most focused on is the acknowledgement that not everyone is going to be building their apps in the same way and that everyone's coming in at some level of "legacy". Don't really like that word, but legacy code base that they're dealing with. So we really want to meet you where you are. Kathryn Grayson Nanz: A lot of people eventually do end up using the KendoReact library. Like I said, we're really on focused some of those big components, but we do also offer all your standard components. Your buttons and your dropdown menus and all of that kind of stuff so that you get that really cohesive look and feel across your application. So yeah, it depends on the problem you're solving, I'd say. Noel: Yeah. Yeah. That makes sense. I guess, with the big components, do those typically have... I guess, presumably they typically have other items in them that are valid candidates to be replaced with Kendo components. Is it easy for me as a dev to use my own button, for example, integrated or something? Are the components largely structural or are they opinionated about how users interact with them as well? Kathryn Grayson Nanz: So we are more opinionated in terms of... If you wanted to replace a button within our data grid with your own button component, that would be a little hard. However, we are very easily styleable. That's a tough sentence. We've really paid a lot of attention to the ability to come in and customize components. So while you might not be able to go in and use your exact button in our data grid, you can absolutely customize our data grid so that the buttons look exactly your buttons. So from a user standpoint, they won't notice any kind of difference look and feel wise and we've got a couple of different options for customizing your theme and getting it to look as much... If you want to use some of our themes out the box and not worry about it, you want it to be super easy, you can do that. If you want to go in and customize it so that it is unrecognizable as Kendo, you can totally do that too. Noel: Got you. Kathryn Grayson Nanz: Which I like to do because I like CSS. Noel: Nice, nice. That leads me to, I think, the more interesting question here of how you balance the need for high-level design continuity that a good component library usually reaches for. I guess even a component library is probably the wrong layer, but a design language or a design system is typically pushing for. It's like, "Well, these things should be the calls to action. These kinds of things should feel like they have these affordances intuitively." How do you as a component library that's positioning something that can be easily consumed piecemeal, really approach that problem of wanting to control the whole user experience? Kathryn Grayson Nanz: That's a really good question. I would say that a lot of that comes down to the focus that we've put on the design side of things. One of the things that I like about Kendo, that is part of what eventually convinced me to jump ship and join the Kendo team was that they're really focused on the designer experience, which isn't something that I had seen before. And a lot of my experiences previously building component libraries myself, was because I had had that frustration with other component libraries and this feeling like I couldn't make it look the way I wanted, I couldn't make it jive with the design system that we already had in place. I felt boxed into whatever opinionated choices that third-party component library had already made. So oftentimes using a third-party component library was a really frustrating experience for me as a designer on a team. Kathryn Grayson Nanz: But we have really tried to differentiate ourselves by prioritizing that design experience. That's part of why we offer our Figma kits and some of the tools and options. The high-level of customization that we do is so that as a designer, you can look at those Figma kits, break down everything that's in our components. It breaks down each one of our components in a true atomic design style all the way down to the smallest pieces. You can customize those with whatever design system you already have in place. Kathryn Grayson Nanz: We've even got tools... We have a Figma plugin and another piece of software called Unite UX that can help you export directly from our Figma kits, customize our Figma kits, make them look however you want, export through our plugin into Unite UX and, then check, make sure everything lines up. That the design lines up with the code. It's got a little slider you can move back and forth and see exactly side by side how it aligns and then export from Unite UX and you get SASS variables, code, CSS that you can drop directly into your application and storybook documentation, which is so much easier. I wish I'd had that, but all in that attempt to bridge between whatever you've already got going on design-wise and our components. Noel: Got you. So I guess my immediate reaction to that is I have a suspicion that most web devs are not working in an environment where... I guess, most design or dev teams are not working in an environment where everything is already well designed in Figma and ready to go. It's like, "Eh, we've got the general structures in Figma but we're still recreating everything manually when we go hand it off to the devs and they do their best, and then we change three things and they change it here and it breaks everything else." But their abstraction of the CSS rules is not necessarily completely tied to what is happening in Figma, right? Kathryn Grayson Nanz: Right. Noel: In that design tool. Does this help with that problem? Are you able to still use these tools? I forgot the name of the one, the diffing tool that you just used. Can you still use that export process in one of these systems that's a little bit disjointed and hasn't been totally married yet? Kathryn Grayson Nanz: Yeah. It's called Unite UX, is the other piece of software. Noel: Unite UX. Okay, got it. Got it, yeah. Kathryn Grayson Nanz: But yeah, it's one of those... We hope that in some of those situations we can help create that, I guess, maybe source of truth is a good word. So if you don't already have a design system in place, then maybe these Figma kits can be the start of that. They live there and they're always the same, right. And the design tokens, we've been very intentional, the design tokens and everything in Figma already lines up perfectly with the SASS variable names that we're using in the components. So we're really trying to minimize that kind of shift that you're talking about. So there should be very little interpretation that has to happen. Kathryn Grayson Nanz: And for teams that really don't have a design team at all or aren't looking to quite dig that deep, we have some easier theming options so that you don't have to go through... If you don't use Figma, you don't have to, we've got a theme builder that lets you quickly go through and customize. It gives you a what you see is what you get kind of preview of how components will look if you tweak the colors for some of our major recurring variables. Or again, we've got a handful of themes right out of the box and you can use the styles that we made to not worry about it at all. Noel: Yeah, Yeah. Yeah. I feel like sometimes that's super nice when you're in one of those situations like trying to build an internal app or something. Like, "I don't care if the button looks perfect. I just need the pretty-looking button." Kathryn Grayson Nanz: Right. Noel: Like, "This'll be perfect here." Been there. Nice. Yeah. So I guess more on that note of the handoff process going from design to dev. So in these orgs, let's say there is a more robust design system in place already and everything's well specked out in Figma. Am I able to use all of that existing work I've already done with Unite UX and still have this diffing process if I'm using a mix of Kendo and custom components? Kathryn Grayson Nanz: Yeah. There'll be a little bit of work that your designers will need to do in terms of syncing up mostly design tokens in Figma, right? Making sure that whatever you've got already in your other file, you can move over into our Figma kits and apply there. But because of how the Figma kits are broken down, it's not super hard to customize because it uses... Figma also has a component system that allows you to change something once and then see it changed across all of your work in Figma and we leverage that. Kathryn Grayson Nanz: So you can just make changes to the handful of super basic components that then using the atomic design structure are replicated throughout everything. So you change the button once, it changes in the date/time picker, and the grid, and everything else. So updating your stuff, shouldn't be too hard. There'll be a little bit of... You want to move all your colors over, you'll set whatever your border-radius and your drop shadows and whatever your design tokens are or your fonts. Once those are set in the Figma kit though, it's pretty easy. Noel: Got you. So are there people using Unite UX without using Kendo at all? Are there people just using it for the cool AB functionality that you know of? Kathryn Grayson Nanz: I actually don't know. I don't have a really good case study or something that I can point to. You certainly could. It's certainly possible because, really, it's just a tool to do that side by side. I would say it's most powerful when combined with the Figma kits, but it does not have to be. I can't answer for sure though. Noel: Yeah, yeah. No worries. It just sounds something cool. Are there other tools in that space that you guys looked at and modeled it after or anything that you're aware of? Kathryn Grayson Nanz: There are other tools, but there's always that kind of... A lot of what we were trying to fix was that frustration with machine-generated code, right? That a lot of times you get with something like that. Something that promises to export directly from Figma, and then you get this weird you dreamweavery kind of code to hearken back, dark days. Dating myself a little bit. But then you have to go through and revise all of that. We wanted to give people an opportunity to see exactly what would be output, make the tweaks right there in that side-by-side view, and then have the chance to not just be stuck with whatever got dumped out of the auto Figma export. Noel: Yeah. Got you. Got you. Cool. Yeah, that sounds super useful for those teams that are just struggling with that. "Oh, I hit the export button and it's kind of there but not really well enough to be used and it's really just that I'm doing this manual code review process that's super unpleasant." Kathryn Grayson Nanz: Right. You end up trying to do that back and forth. You got Sigma open in one window and maybe Storybook in the other. Been there, done that. Noel: Yeah, for sure. For sure. I guess, yeah, maybe on that note, we talked a little bit about your history before and working on libraries from design. Have you been working on other component libraries in the past? Is this the first team you've really been on for first party? Kathryn Grayson Nanz: So I've done some custom component libraries for a couple different companies, but yeah, I worked at a place called Herman and they did a really interesting assessment that was like a Myers-Briggs, but to measure your thinking preferences and how you approach problems. They had a whole application that went along with that to give people their results and I did the component library for them and their design guide. Kathryn Grayson Nanz: And then spent a little over a year at a place called ThreatConnect that did cyber security and worked on their component library, started that from the ground up as well. So I've had a bit of experience building really customs solutions and both of those places were building applications that were so specific and that needed very custom mostly data visualization type components where a third-party component library wasn't necessarily the right fit for them. Noel: Got you. Got you. Yeah. Yeah. That was where I was going to go with my next question is I feel like it's interesting to me because there's... I look at the really fleshed-out frameworks that are implementing design languages and stuff, and they feel like... There's large teams working on these. There's a lot of energy being put into building and maintaining these things. Do you feel that most companies should be in the business trying to build out their own component libraries for everything like Data Viz and stuff? Or if you're a fledgling web company, where do you make that line of, "Eh, maybe we should start with our own component library before reaching for something off the shelf and then tweaking it." Kathryn Grayson Nanz: I think it really depends on the makeup of your team. I think that has a huge thing to do with it and if you have a designer or you have a team of designers, then I think you're in a really strong place to consider maybe building your own. I think it also depends on the application that you're building, and touching back on previously, how many truly custom components that you need and you have to weigh where the time is best spent. I would argue that very rarely is any engineer's time best spent rebuilding a date/time picker. Nobody's in enjoying that. No one's having fun. There are bigger cooler problems that you could solve with that time. It could be better spent. Kathryn Grayson Nanz: So I think in general, my approach is to consider a combination, right? Where you could bring in a component library to fill either the really basic components that it feels not in your best interest to rebuild or they're really complex components right? But take a huge amount of time and a huge amount of manpower to rebuild. And instead, focus that time on creating the things that are truly custom differentiators for your application. Kathryn Grayson Nanz: So like when I worked at the place that measured the thinking styles, they had a huge amount of data visualizations that broke down things according to their specific system and showed where you landed on a graph and where your coworkers landed and comparisons and all of that kind of stuff, which wasn't something you could've pulled out of a third-party library. So our time was better spent on that because those took a lot of work. As opposed to text boxes and buttons and drop-down menus and we could have saved a lot of time. Noel: No, for sure. Kathryn Grayson Nanz: We didn't. Noel: Yeah. But I guess even in those apps, I'm just thinking... I would assume that most companies, even if they have really bespoke, some specific views that are really domain-specific, there would still be date pickers, right? On the, "Oh, I'm filtering my data. I still need it." 90% of my design elements are still things that are super ubiquitous shared web standard stuff. Kathryn Grayson Nanz: Yeah. I think at this point there's very little value in rebuilding that kind of stuff yourself. Especially I would say now where we have such a high focus as it should be on accessibility, right? Noel: Mm-hmm (affirmative). Kathryn Grayson Nanz: And that's not something that necessarily every developer is super well trained in or super experienced in. So anytime you bring on that task of recreating a basic component, you also have to take on making sure that that's accessible to all of your users. And if you aren't 110% sure that you can do that, then again, it might not be the best choice. Noel: Yeah, yeah. Yeah. I feel like it's one of those things where it's just like it's such a rabbit hole of building a well fleshed-out component library that can do everything. I feel like even as a dev, it's just like... When you go reach for one of these off the shelf, it's just like, "There's so much I'm assuming that is being done for me that's like." I don't know, like having a clean aesthetic overall and theme and accessibility and just not having to think about that is such a huge boon. Kathryn Grayson Nanz: Yeah. The thing that I think about is that we have a whole team of developers for each one of our Kendo libraries, right? Noel: Yeah. Kathryn Grayson Nanz: And if you have the same amount of people at your company and you can dedicate a whole team to it, then God's speed, you know? Noel: Mm-hmm (affirmative). Kathryn Grayson Nanz: But I don't think that's a position that a lot of people are in. I've seen just the amount of work and time and care that goes into creating the kind libraries and I think that's a... That would be a tough bar to meet if you were... Also, your primary goal was something that wasn't that. That was actually creating your own application. Noel: Right, right, right. Yeah. So I guess I'm curious, when you were working on these component libraries of these smaller organizations, were you looking at anything that was guiding you in terms of spacing ratios around text, and buttons, and corner curves, and how far to space the buttons, and positions and stuff like that? Because I feel like with some of these UI frameworks, design languages, that's materials' whole thing, right? It's super, super opinionated all the way down to that level. Was that something you were concerned about at the time or was it just like, "Yeah, that looks pretty good." How did you do that? Kathryn Grayson Nanz: Yeah, I would say that kind of stuff was pretty high priority to me and was a lot of the reason that I got brought on is because I did have that traditional design background. And so rather than that, "We'll just mirror what these people are doing." Or whatever. When you have that design education and that understanding of why we're putting this padding here and what's the end goal of making these design choices? What are we accomplishing and how are we doing? Got a little off on a tangent there, but when you have someone on your team who has that knowledge, you can make those choices in a specific case-by-case basis. Kathryn Grayson Nanz: And that seems maybe a lot for setting the border radius on a button but all of those things come together to create a user experience that ultimately should feel unique to your application. I think we went through a period of time where both bootstrap and material design versus super recognizable everywhere. You could open a website and be like, "[inaudible 00:29:30] material." And I think that's not the end goal, right? That's not the ideal. It looks good, but it doesn't look you and you always want it to look you. Noel: Yeah, totally. So I feel like then the trade-off that, again, a developer is trying to land on is, "Well, I want it to feel me, but is it even feasible for my app to feel its own unique thing and still feel clean, polished, and sharp without spending as much time as I am building my functionality on figuring out the padding around the button text?" Right? Ensuring that all feels natural and elegant and non-obtrusive. So is that something Kendo is trying to do. I guess maybe more broadly, do you guys think at that level? Like, "This is how padding and spacing and all that stuff should look." And that instructs the component library still? Or is that not really how you guys go about implementing new components? Kathryn Grayson Nanz: I would say that comes down to the theming and our approach to theming and styling, right? Noel: Yeah. Kathryn Grayson Nanz: So I as mentioned, we have a handful of themes that we've made and you can leverage them. You don't have to think about design or padding or anything at all. With that, does come the trade-off of maybe it doesn't look exactly. I don't think you quite run the risk of it looking like everything else, but there's a middle ground there, right? Where you don't know if it looks necessarily unique, but by opening up all of our components and letting you style things and customize really heavily, if that's something that's important to you, if you have a design system, if you want to make those kinds of changes, then we have absolutely full support of coming in and making it look, yeah, however. So that you could look at a website and you'd never go, "Oh, that must be Kendo." Because it would look whatever you did. Kathryn Grayson Nanz: And I would say, I think obviously that's a lot of the reason why design systems are really big right now is because a lot of people create that feeling of creating something that feels really unique and that feels really different. And that's the benefit of those kinds of systems, is you spend whatever amount of time upfront chunking out those styles and determining what feels like you and what you want your look and feel to be like. And then you have that, you don't have to keep making those design decisions over and over and over again. Noel: Yeah. Yeah, I feel like- Kathryn Grayson Nanz: Hopefully, ideally, I would love to see people grab the Figma kit, you'd make those design decisions, you'd apply them, you'd export and then you would just be set, you know? Noel: Yeah. Kathryn Grayson Nanz: And then of those design decisions would be the hardest and the most time-consuming part and implementing them would be easy. Noel: Yeah. Yeah. I feel like that's always been the dream, right? Everyone aspires to have this... I guess from the design system, all the way down to the CSS rules, like clean abstractions. "And we decided we want the padding around here to be bigger and I change one value and everything just looks great because it's all wired up." And there's a whole spectrum one can fall on there. But yeah, I feel like having these tools like Figma and pipelines in place for design, I feel like we're hitting a maturity there that's making that quite a bit... If not easier than easier to aspire to at least. Kathryn Grayson Nanz: Right. Noel: Yeah. Yeah. Very cool. On one of these teams, you feel you've got the component library pretty built out. You have a large team of devs just working on this. What is the ongoing work that needs done? What are the things that you guys spend cycles on once the core components are built out, look good, you have the pipeline in place for users to use, the customizability options are largely there? What is the net new dev work on? Kathryn Grayson Nanz: Usually split between a couple of things. So obviously adding new components. We're always adding new components, we're always listening to user requests and there's always something out there that you wouldn't have thought about that it's like, "Oh yeah." Once you have. Recently, I think we're adding a PDF viewer. We've been in process. I'm doing a task board, a Kanban-style task board. We added in the last release a QR code and a bar code generator. There's all kinds of little stuff that will come up that's outside of that realm of the usual buttons, menus, whatever. The more we can add, the more you don't have to look elsewhere if you have one specific component that you really need. So that's a huge part of it. Kathryn Grayson Nanz: Accessibility is another primary focus, especially because that's always evolving and shifting and we're learning so much more about how you can be better at that kind of stuff. How we can build things better, how we can be more accessible, how we can test more thoroughly and accessibility standards are changing along with that as we in a more universal sense, learn more about what we can do to better accommodate our users. So that's another big focus. Kathryn Grayson Nanz: I'd say the last one is probably performance. Just because yeah, dev-wise, there's always somebody who's going to be interested in getting in there and fiddling and seeing if we can make it a little bit smaller, just a little bit faster, just a little bit more performant. So yeah, I'd say those three things probably take up the majority of the time in the dev work. Noel: Nice. Nice. Yeah. Very cool. I guess that segues us nicely into what's coming out in Kendo right now? What's new? I know you spoke about the QR code component, the cards component. Is there anything else cool on the horizon? Kathryn Grayson Nanz: Yeah. I'd say I think the two big ones in our next release are likely to be that task board and the PDF viewer. We've also been revamping some of our style options and trying to expose more of the styling options to give you, again, even more granular support. So we're going through there, going through each of our components and evaluating, "All right. How can we make this hook in a little bit easier to existing styles? How can we make sure that you have access to variables and can drill down easily and not have to write a whole bunch of importants?" So that's been an undertaking that's been going on. It started with our last release and it's going to be continuing. And we are, again accessibility-wise, we are already AA compliant from a WCAG standpoint. Now we're looking to move that to AAA wherever we can. So that's been a huge focus as well. Noel: Nice, nice. Yeah. Another benefit of reaching for a library first and building from there. It's like, "Oh, we get all these niceties out [crosstalk 00:36:35]." Kathryn Grayson Nanz: Get all these little things for free. Yeah. Noel: I don't have to worry about. Again, not that I don't want to have to worry about them, but it's just another thing on the list and if it just works for everyone. If it works for a larger swath of people, awesome. Super cool. Yeah. I guess the only other question I'm curious about and I wanted to circle back to this more proprietary are UI frameworks focused at larger enterprises versus these open-source, this easy to jump into but harder to get support frameworks is I'm curious what the community around Kendo feels like. In comparison to these other framework servers like Discord servers and Slack channels and stuff. Or that seems to be the support, right? It's like, "Well, people congregate there because they need help and they can't figure out how to do something and then they end up hanging around and eventually they become, or some subset of them become experts and hopefully share that knowledge." Do you see that process happening regardless with Kendo? Is that still occurring at all? Kathryn Grayson Nanz: We have a little bit of that. So we do have forums and we do have... Obviously, we have support team people who are actively engaged in the forums [crosstalk 00:37:47] to that, but we also have people that have just been Kendo users for a long time and really love it and they tend to be active there too. We have a program called Progress Ninjas. Noel: [crosstalk 00:37:58]. Kathryn Grayson Nanz: Progress is the parent of Telerik who creates Kendo. I know that was like a waterfall. But our expert users, we call ninjas and they are... We do have a Slack community for them. And so there's a lot of good communication and sharing that happens there. We also tangentially on the DevRel team for Kendo and all of our products have a shared Twitch channel where we're super active. Streaming, gosh, pretty much every day of the week I think, one of us. Kathryn Grayson Nanz: So we have the CodeItLive Twitch channel and we've actually been able to create a really amazing community there. It was something that really surprised and impressed me when I first joined the team and started streaming myself. I'd say we have a really cool group of regulars who will show up and hang out and chat, not even necessarily about Kendo. Just about developing and building and design work and whatever they're working on. It's really cool to be able to get on stream and just hang out with our community and chat or build or talk about whatever, even non-dev related. We were on last Friday talking about fantasy books and general geekery D&D games and whatever. So, yeah, we get that community. It's a little bit different because it's not as support-focused, but I think in a way that's nice too. Noel: Oh yeah, yeah. Yeah, totally. Yeah. It's nice when the discord server, channels aren't all just flooded with people always asking questions. It's just like, "I want to be here and support this community, but I don't want another full-time job supporting my library that I'm trying to help here." Yeah. Nice. Nice. Super cool. What are you usually working on when you're streaming? What's your... Kathryn Grayson Nanz: Oh, I've got a couple streams that I do regularly, both on Mondays. So Monday mornings, I go on 10:00 AM eastern time I do a show called Dev by Design where I talk about design fundamentals geared towards the developer audience because that's something, again, we touched on it here. But there's a lot of developers really struggle with being able to put things together that they feel look good or professional and just I feel like if they knew just a little bit more, if they had access to some of those basics in the same way web designers, UI designers have to learn so much in terms of development fundamentals, but very rarely is that swapped. So that's the goal of that show, is to get on and chat design and talk fundamentals for a little bit every day. Kathryn Grayson Nanz: And then me and my coworker, Alyssa, have a show in the afternoon on Monday at two o'clock Eastern called UI Mondays. And that one's a little bit more grab bag. We will either talk about what's new, or talk about what's trending, or we have guests on, or sometimes we just build, work on whatever we're working on, but it's a little bit more of anything front-end kind of grab bag. Noel: Is there anything else you want to plug or shout out? Point the listeners to? Kathryn Grayson Nanz: Probably just the conference season that's starting. We're going to be out and about, me and a couple other of the DevRels from Progress will be at CodeStock in Knoxville in, gosh, just a little over a week next... Not this Friday, but next Friday. This won't matter. It's going to come out on a podcast probably after it's done. April 7th to 8th. Noel: Podcast time. Who knows? Kathryn Grayson Nanz: [crosstalk 00:41:32] questionable. I'm too used to that Twitch streaming. Noel: Yeah. Right. Kathryn Grayson Nanz: And then we'll also be at React Miami at the end of April and yeah, a couple virtual ones that we're doing as well. I'll be at Hover, the CSS conference at the end of April, as well as the Women in Technology Summit. So they keep coming and they don't stop coming. Kate: Awesome. We'll include those links in our show notes. And Kathryn, thank you so much for joining us today. We will see you around. Kathryn Grayson Nanz: It was really fun. Thanks a bunch. Kate: Thanks for listening to PodRocket. You can find us at podrocketpod on Twitter and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.