Wrong one, wrong one. That's okay, good morning and welcome to this week's edition of Encompass Live. I am your host, Krista Porter here at the Nebraska Library Commission. Encompass Live is the commission's weekly webinar show where we cover a variety of topics that might be of interest to libraries. We broadcast the show live every Wednesday morning at 10 a.m. central time. But if you're unable to join us on Wednesdays, that's fine. We do record the show as every week as we are doing right now. And it will be posted to our website for you to watch at your convenience. And I'll show you at the end of today's show where you can access all of our archives, both at the live show and the recordings are free and open to anyone to watch. So please do share with your friends, family, neighbors, colleagues, anyone you think might be interested in any of the topics we have on the show. For those of you not from Nebraska, the Nebraska Library Commission is the state agency for libraries in Nebraska. And this is similar to your state library. And so we provide services to all types of libraries. So you will find shows on Encompass Live for all types of libraries. Public, academic, K-12, corrections, museums, archives, et cetera, et cetera. Really our only criteria is that it's something to do with libraries. Something cool libraries are doing. We bring guest speakers to share what they're doing. Services and programs that libraries could benefit from. We do book reviews, interviews, mini training sessions, demos of services and products could be anything. As I said, we bring in guest speakers sometimes. But sometimes we have Nebraska Library Commission staff do presentations for us today. And today is a special day. We're starting something new, a new four-part series today on teaching technology in the library with Amanda Sweet, our technology innovation librarian here at the Nebraska Library Commission. Good morning, Amanda. Good morning. So we're going to find out today who is learning and why. It's true. So I will hand it over to you, Amanda, to tell us all about it. So first I'll dig into kind of what we're going to go over here because this is actually a completely new series. I'm trying something very new here. I'm very excited about it. I hope you are. So what this is all about is one of the major questions that I've gotten is how does instruction actually evolve? What does it look like through the stages and how can I start learning this process so I can try it myself? So what I'm trying now in the teaching tech series is to kind of poke through what's under the hood of putting together one of these courses and trying to figure out what people need and figure out how to put it out there. So a lot of times people are kind of tempted to wait until everything looks perfect before it just goes out into the world. But as it turns out, that's not really recommended anymore. What's recommended is to kind of use like a rapid iteration process so that you start just getting the idea together and start putting it in front of people as soon as you possibly can. So if you do go over to that link that I sent over for the teaching tech series, it's not going to look perfect. Nothing is ever perfect. But the purpose, like the whole purpose of this is to test the idea. It's to put it out there, get the feedback and fix it as you go along. So I'll start off with going over what the teaching tech course is actually all about. And then I'll go over some of the iteration and design process. We'll talk a little bit about user experience design and the bulk of this is going to be digging into some of these techniques, which might be why some of you are here. And so this is actually what's going to be in the course. This is what you are learning. This is the subject matter content, the who is learning and why. And the user experience design is just tied into it. User experience is basically how can we build a product that fits into the flow of people's everyday life. And when you think about it, any library service, it's a product. If you if you do like a book discussion group or a knitting club, or if you do a code club robotics club, you are actually designing a product. It's something that is made available to people, and you're supposed to be choosing a time of day that works for people. You want to choose content that works for people.  And that is the heart of user experience design is I want to be able to offer this new technology course. I want to be able to offer this new library service. But how does this fit into people's lives is this working into the flow of people's everyday life. Is it. How is this working. So that is why we touch on that user experience design some of you may have already made some of you may already use it already some of you might be new to it. And it's kind of I'll cover some stuff you might know some stuff that's new. So let's just start at the top here the what is the teaching tech course. So the teaching tech course is basically designing a library service it's designing the products in the library that people are actually going to see. So there is a kind of a general process to designing that product. So some of this process you might already do in other ways, but we're going to take a user experience approach to it. So everything that I'm talking about now is going to come from the perspective of user experience design and product design. And I'll also be using some startup principles. So startups are really good at rapid iteration and design, and they are really good at testing things out and not putting too much into an idea and tell you actually know that it works. And since libraries have really limited time resources and energy to put into all this stuff. Those startup processes have actually been incredibly helpful so far. Because why would you put all the time energy and money into something that's just going to flop. So that's why we start off with who is learning and why the who is learning and why section of this designing a product for the library is finding out what makes people tick. What are the problems people are facing what matters to them. And if you're going to design a product or service that is going to fit into the flow of people's everyday life you need to know what people's everyday life looks like. And you need to know what matters to people, the bigger the problem people are facing the more likely they are to take action to solve it. And when you design a product that flows into a person's schedule and you develop resources that people can use in the moment. And you understand how people are learning this stuff versus how people are using it in everyday life. Then that is kind of the heart of figuring out who's learning and why. And you would just want to know, why should people care. So you're going to teach a robotics class or you're going to teach a Microsoft Office class or a Microsoft Excel class. Why what's the purpose of it. And a lot of times we start off with Googling a top 10 list of the most popular technology and then trying to design a service around that just because it's popular. But that's not always the way that it should go. Instead, you want to start with the problems people are facing and only offer the technology that fits into solving that problem. So if you've ever done a event or hosted a class that no one attended. That could be why. And it could also be the marketing of the course. Did you actually draw from the reasons people would actually be going there or did you just say, here's Excel do it. And so then the later series of these of this course will be digging into breaking down the problems that people are facing step by step. And saying, okay, we found out that older adults that are recently retired, they're now looking for the next stage in life. We want to know what they're facing right now they're trying to figure out retirement they're trying to fill their lives with other hobbies and they also want to stay connected with their friends and family. So now we want to know what their actual day looks like what they're facing how much time they have when they're actually free during the day. And then you pluck out one of the major major problems that the that that group is facing, and shift over to this next phase, where you break that problem down into smaller sub topics and say, this is the entire process that people are facing right now. These are the smaller problems people are facing. This is the these are the areas where the library can actually help. There are organizations within the community that are working on finding a solution. And these are this is where the library can route people to help solve this problem and this is how we can help with these particular aspects. So, and that's going to vary a lot depending on the actual problem we're working on. Some of it's going to be easy. Some of it can be solved with just an infographic that's sitting next to the computer lab in the library. We might need to have a much more complex solution that works with other partners within the community. And that's what we dig into in that next section there. And the third section of it is okay we know who's learning we know what they're facing but people still aren't showing up. Are there other ways that we can be doing this are there other ways that we can teach this stuff. One of the common things that libraries do is to do the TED Talk style events. There's workshops, there's trainings, there's group trainings, reference interviews. There's just a mess of stuff that we already do. So how do we choose the best option from the menu that's currently available or how do we create a new option based on the new needs that people are facing. So we'll look at some different ways that instructional design has been happening. Some new ways that people have been teaching both online in person and in a hybrid format. I dig into a lot in instructional design and technology because technology is the thing. And then once we have kind of a choice of what how we actually want to teach this, then we'll start gathering resources and securing down partners within the community that might be able to help with this. And sometimes for some stuff you don't even need a partner, you can just go do it. But for the more complicated stuff like job searches or career changes or career exploration, things like that you probably need a partner for. So you can map out the different organizations and you'll actually continue this process iteratively as you go along. Because you might also choose a problem to focus on based on who's available to help. And you might also start returning back to the stage once you've brought on a partner who knows more about the topic. When you brought on the partner that knows more you circle back and start adjusting the previous phase. And so once you've started gathering the resources, then you'd need to figure out. Okay, so we just decided to enter in a new space where we're going to be teaching some of this stuff. So how do we prepare staff to do it? How do we help our library staff volunteers or advocates deal with this new material? What do we already know? What do we need to learn? And when are we going to learn it? And then how are we going to maintain accountability and stay on track during this whole process? So that is the preparing staff and material section. And then the last little bit of this is the marketing and follow up. So if you circle back, remember this is iterative, you want to circle back to the who is learning and why. If you are marketing a class on Excel, what kind of images are you going to use to pull people in? Is it going to be a computer? Is it going to be an image of a financial services office? Because you're going to be using Excel to build a budget for a savings plan so you can go on vacation. How are you going to, where are people in their everyday life so that you can connect people with the information they need? And how are they going to find you? When you understand where people are and meet them where they're at, then you can choose the best marketing route to be able to connect to them. And then you can start learning the tools and resources that you need to improve that marketing technique. And this marketing is also in the user experience and interaction phase. So they use that a lot in startups. Startups and libraries have a lot in common as it turns out. And so some of the same techniques that I pulled from startups and local businesses, you can use in the library too. Startups love free things and so do libraries. They get along. And the follow up part of this is how do you find out whether this new service that you, this new product that you designed for the library, how do you find out it worked? And how do you gather the data and gather the stories, gather the information to show that this is the thing that you should be doing more of? Or this is a thing that needs to be adjusted and how? And or is this just something that didn't work? So we just scrap it and start over with a different thing. So that is kind of the major steps of actually teaching technology in the library. You might get through all six of these steps in less than a day or a week. And you might take maybe a month or a few months to work through this depending on how complex the problem you are facing. All right. So our main focus in this, this is a lot. I understand that I've been told that I get it. Which is why we split it up into multiple sessions and don't you're not going to learn all of this the next hour. No, not at all. No. So don't panic. So we are living right here. The who is learning and why this first stage right here. So to understand who's learning and why I dug a lot into that iterative design and how to grow your idea over time. So these are two of the books that helped me a lot in learning it. So instead of me watering down and talking about a lot of these topics, I'll just send you directly to the source and try out design for how people learn. This was kind of an awesome resource for learning how to play up a white space learning how to organize materials and resources and learning how to work with both small and large teams to make this happen. Because each different library in every different community is structured differently. And they have a different number of people that are allocated to work on these projects. Some people might have a team of one, it might be just you. And some people might have a team of five, six or more. It depends on size of library and how much you are devoting resources to this project right now. And the design thinking playbook has been invaluable. Even the format of these pages are different than your average book. It uses a lot of full color imagery plays on white space you can learn a lot from design just by looking at how they design this book. And it's playful catches the attention, and it also shows how products evolve over time. And everything you design in the library can be seen as a product. As I found out. And even though this is sometimes geared toward businesses, a lot of it crosses over. It's a product is a product is a product. So these are some others that I found really helpful. If you are looking for the source material. I pulled a lot of the basics from some of these resources and there's also a variety of other resources I grabbed from my main goal is in designing the course was so that you didn't actually have to read through word by word. All the different stuff that I had already read. I plucked out the stuff that you actually need in the moment and started baking it into the actual course. So you don't have to read this but if you do want to if you want to know where I got it from or if you want to learn more about it yourself. These are the places that I went. And along with about 20 30 other books just over time. It took a minute but there, there's about a billion and one resources. The user experience team of one is incredibly helpful if you're a solo librarian or if you are the only one in your department working on this stuff. And this product. Yeah, very important to many of our. And these are these 2 on the right are good if you are getting into teaching online. So teaching online is a different animal. And so if you are used to doing in person stuff and only in person stuff recently that hasn't been an option. And now that it hasn't been an option and people are getting used to the idea of everything being available online. This is now a space where libraries need to live. And so you may have already started shifting over and said, we tried online. It doesn't work. We're going back to in person. But a lot of that could be just the style that you were using. And it could have been the activities that you chose and it could have just been that it didn't fit into people's everyday life. So instead of just calling online a wash. Maybe try something different. And start thinking about the design process and how it fits with people. Alright, so if you want to learn other things about user experience design I have these embedded into the course itself but they're also available in the slideshow if you want to quick access. These this is one of the best books that I found about designing products and I pull a lot from it and near Al he's out of Stanford he's delightful. I went to a few talks from him and he's just awesome. And this is this is just another list you can grab it read through it at you as you like. And some of these resources are baked in but I put them into the slideshow just for easy access just because I haven't completely finished updating every little nuance of the course. And I mentioned you while you're seeing all these links that as part of the archive you're going to you'll have access to all of the of Amanda slides to. Don't worry about trying to scribble down these titles these names of these places or anything about what worry about what the link actually is, you'll have a link to these Google slides and be able to click right on them. I will actually just share it now. Yeah, just in case. Copy, and I will put this into the chat if anyone is curious about it. There we go. So that is the slides. And so now we'll actually dig into the course itself. So this is the course page of what you would actually be looking at. So if you remember I said that when you put out an idea try to put out the concept as soon as you possibly can. Instead of waiting till everything looks perfect and putting all of your time effort and energy into making it look awesome. You can see that this is primarily it's text on a page. And it's sectioned out just by regular category you've probably seen this on about 8 million and one different websites and pages. But then this is what it starts to look like over time. What I'm doing right now and this is kind of the looking under the hood process of putting together a course. Is I'm putting the idea out there and making sure that this concept model actually works. So I've already done about four workshops that run through this different process. And as people learned and understood the general process I found out the different aspects of this process people are most likely to use. And then I found out and remember I'm using user I'm designing within design it's kind of trippy but it works. Because I'm designing the resources that are going to be used by library staff library staff are designing the resources that are going to be made by patrons. So I have to understand the process that patrons would need. But then I also need to know how library staff are going to learn this so that they can extend it to patrons. So it's kind of design baked within design. So the workshops were with library staff as library staff start using this model to go out into the world. And as I start using the same model and other things that I do. And as I reach out to actual patrons and maker spaces and things like that this idea evolves. But the whole purpose of this was to put it out there. And now that people started understanding these stages. I started I can iterate now. And I can start figuring out the progression of how this should actually change adapt and I can grow resources that people can use in the flow of everyday library life. So what I started doing was bucketing out the different categories of users within library land. And within that, I started bucketing out the categories of users that are within the community itself. Because they're different. And so that's something that I have to worry about. But most of you probably don't. You probably just need to think about one layer of this, which is how do I connect this over to patrons. How do I help patrons connect with this information. So the good thing is that you don't actually have to always worry about that other layer unless you're working for a state or regional library. Some of you might, but you might be in luck. And so the who is learning and why I'll click that open here. And I'll start talking about the methods that you can actually use and what might be most relevant for you. So, of course, you can click open this link and just start reading it. You might have actually already done that. So I'm going to copy this link in for people who haven't already accessed it. And teaching tech course link. So I'll talk you through how some of this came about, give you some design tips and start talking about the different methods that have worked what hasn't worked and what you might want to try based on the context of your library. And so if you, if you sift through this top section, it's going to talk about why the stuff matters. And start of what are you at what people have run into when they've skipped this step, everyone what everyone wants to go straight to we are teaching people robotics, but they skip why. And they skip over. What are people going to use this tool with in the in their actual lives. How does this fit. Cool buzzwords out there right now and things that grab people's attention. Yeah, but if you skip the why you're you're you're just showing something cool and fun and then nothing ever comes of it and what was the point. Yeah, it's why a virtual reality is awesome. And it is indeed functional. But it's been falling flat. What if you think about think about the last technology that's actually mattered to you. What is the technology that is actually made a difference in your life and is impacted your life. And what this is what matters. This is, and that might actually look different based on context. The technology that made a difference at work is different than what made a difference at home is different than what made a difference when you're at the community garden and trying to share who's going to be watering the next plant round. And a lot of people don't understand the technology that exists to help them in the problem space that they're living. So that is the value of the library right now is if we understand the problems people are facing. And we are able to break that out into segments and be able to connect people with technology that can help in their everyday life. That's invaluable. And so and that is and another thing is building a menu of technology that's available and just having that available for yourself and library staff. So you need to actually understand a little bit about who people are and what makes them tick, then a little bit about the technology groupings, and then a little bit about how to actually incorporate this into their lives. So how do you actually find that out. That's why we're all here. The who is learning and why there's a little blurb on user experience. I just talked about that. But these are some of the questions you want to start asking people. So this little segment right here. Instead of just asking what technology do you care about. That's like ask that's sending out a survey that's like, if I sent out a survey and I asked you, do you need to know more about user experience design. You'd probably say, no, why do I care about that. Or if I say like, do you need to know about robotics, you're going to be like, maybe I don't know. And then you'll probably you might check it off because you're curious about it. And then the library says 82% of our respondents said that they wanted to learn more about robotics. We're going to do a course on robotics. And you do a course on robotics. Nobody shows up. Because I didn't know what they were asking for. So instead of ask what keeps you up at night. What are you worried about. Because what keeps you up at night are the problems. What keeps you up at night is I am trying to update my budget and my kids need to go on a field trip, but I don't know how I'm going to pay the expenses for it. Or I am about to retire but I don't know how to make sure my retirement savings are intact. What keeps you up at night. And what are you worried about right now. What are your priorities in life right now. And just asking open and questions like how are you feeling about a situation. How do you feel about work right now. How do you feel about your current relationship. Do you feel good about your education. Do you know what do you know what your next step is in life. And do you know because people don't always know what to do next. That's why the library offers career exploration services is because people don't know what exists. So if they don't know what exists they don't know that they want to do it. And so once people figure out what they want to do. How do you break that down into stages so that you can start learning it. And is it the library that's going to help with that or is it going to be a partner organization. And how are you going to help people understand the process of being able to figure out what they want to do when we're in why. Because we want to look at people as a whole person. Not just as a tick mark as someone who just attended our latest event. And so these are just different phrases that you can start using to start pulling this information out of people and start understanding what people are facing what they need to do. And what they don't know. So what they don't know is where the library can help. And so this is what you want to ask but the techniques are actually how you do it. So this day in the life process is actually mapping through day by day by day to say, well, this is what you do when you wake up. And this is what you then you get the kids ready for school. I don't have any kids. I'm just assuming that's what you do first. Probably that's what my brother does. Feed the feed the frog. Yeah, yeah, your pet sitting whichever work. Optimus Prime got to keep them fed. But so what are people actually what is their day to day. And when you understand their day to day. That's like rooting yourself in the reality of life. And that's when you would start figuring out what time you're going to offer these different services. It's when you're going to dig in and say and you're going to choose your format for how you're going to offer this because if you realize that people need to pick up their kids from school then they go cook dinner. And you know that the library is a 15 to 20 minute drive away and they only have a one hour block of time before they have to start the next thing. Then the odds of them actually making it into the physical library location get lower and lower and lower as you look at the actual schedule. And when you realize what people are facing in the rest of their day. Then you also realize that it's not necessarily the actual service that the library is offering that is wrong. It's not the content that's wrong. It's how it's delivered. Because you can fit an hour into the day more easily right before you go to bed. Then you would right after dinner like you wouldn't like at six or seven o'clock you wouldn't have time to just duck out go to the library doing an hour or two hour long workshop and come back. That's the disruption of your time. That's why higher education is changing right now. It's because not everyone can disrupt their entire lives and center their lives around schooling. You can't make money doing that. But and you can't support yourself and pay the bills while you're doing that. But if you're taking classes online when you can then it's different. So what can actually be taught online what can. And when you understand this is part of knowing what people are facing on the day to day. But then the problem like the problem prioritization is people have 99 problems. But what is foremost on their mind. What is keeping them awake. And part of the way that you can find that out is during writing groups. So writing groups people and if you know your reader advisors then they know what people are reading. Then there is there's a privacy component to that. But you can also aggregate the information so that you can remove that privacy component to say what types and topics of books are people most interested in right now. What is on people's minds on a community level. And so if you pull that metric. And if you start looking at. Writing groups and story and reading groups book groups discussions and say. I know where we just talked about this book a lot but I just want to take five minutes to just find out. With state the project that you're working on just briefly and say I want to find out what matters to you. I want to find out. What you're facing in life so we can figure out the best way that the library can help. And you'll probably find that people love to share their problems. Because they know that when they share a problem. They're that much closer to finding a solution. So if at the end of a writing workshop or at the end of a book discussion you just ask that and start jotting down the answers. And start figuring out what people actually need in an organic way. Then you can start doing the UX research just over time doing the stuff that you already do. So at the end of a book group knitting group. Wherever people are already coming in. Ask them. They're already thinking about it. And you can also do this and kind of a either community conversation or informal conversation. The community conversation. The American Library Association has a whole guidebook around it. That is kind of the formal version of it where you bring people together have like a little format of questions that you want to start asking. This is how you can uncover community wide problems. But not just don't just uncover the problems people are facing uncover the problems that people actually actively want to take action to solve. Because some of them are just problems that have been there forever in a day. And you either need a new way to solve it you need new people looking at the problem. Or you need to have a different approach. So these community conversation formats can help a lot with this. I have all the resources that will actually guide you through doing this I just since I'm frog sitting right now I can't remote into my computer workstation till I download the right program onto this computer. So that's why I haven't updated some of the resources that are available in here but I do have them. And if you're curious about like you said this is a work in progress being developed as you're doing this intro courses for sessions for us here so that's okay. I will grab the community conversation workbook. Just as a reference if you want to know what I was talking about. And I will put this into the chat. That is just one that I happen to have off hand. So there we go. I have worksheets for this day in the life one. And I have a worksheet for the card sorting. And there's a ton of resources for the field studies and resources if you already work in libraries and you've done some research you might have already known these methods. But there's also some new ones that were specifically made for user experience design. And these are in the Nielsen normal group which is kind of one of the biggies and UX design. So if you want to learn more about these research techniques and some of these I just made specifically for libraries like the what's your story. As far as I know I don't actually think UX designers actually do that. The reference interviews library specific question tracking is library specific. And to some the card the card sorting is rooted in the UX design that I adapted it for libraries. It's interesting that we've always done the reference interview and asking for stories and for advocacy and things. Probably didn't realize that that was what you were doing researching these techniques for what people really want which is you which is user experience. You know what do they need to answer this reference question what are they really asking for we've been doing that already and didn't realize that skill can now translate into this bigger these other projects and things other trainings that you might want to do. And fun fact, just like a fun UX fact. The reason I chose these and formatted the way they are. It took a probably a few years to do it just learning the process. But I had to understand the everyday flow of life for the librarian then I chose UX research techniques that fit with the flow of life. What do you already do how can you play off of this. Because a lot of the UX research techniques that are used in small businesses they didn't always translate over. And there's about eight the million different research techniques. These are just what bit best with the flow. And card sorting is the next one I was going to touch on. So card sorting helps people figure out what actually matters to them. So one of the biggest things that people have run into is when you ask people what their values are. They will either stare at you blankly or it's just say like honesty or something like that. But it's not something that a lot of people have always thought about. So instead of just openly asking what are your values and getting a blank stare or something that people made up on the fly. You can write down a series of values on either posted notes or index cards.  And ask people to review over and sort these values based on priority. And you can do that in phases you can say choose your top 20 choose your top 10 and now choose your top three to five. And then people start actively thinking about what actually matters. You can do that with values you can do that with actual technology tools. You can say we offer courses or materials or resources on these 20 different technology tools. Or we're thinking about doing these 20 different technology tools.  Make a set of cards for problems and then make a set of cards for technology tools and ask people to start playing matching. Or just ask your library staff to start playing matching. Because if you can't match a problem card with a technology card. Then you're going to have a mismatch you're going to be offering a technology tool that doesn't match any problem and no one's going to show up. Or it's going to go the way of VR and it's going to be really, really cool for a second and then it'll go to the wayside by the way of VR connection be really functional just side note there. And I'm sure there are places using you have, you have things like the medical areas where you can see the inside of the heart and things like that. I get those. Yeah, but it's few and far between unfortunately. Yeah. And. Oh, sorry. At the moment. And that's the other thing is that you might introduce people to a new technology tool and they'll have a problem that they can match it to. So possibilities. And there's also helping people prioritize their life goals based on card sorting. Because if you ask people to write out there just brain dump all their problems onto a set of cards. And say, okay, now organize these problems. The human brain can only focus on maybe about 4 tasks at a time which ones would you want to prioritize so that you don't go crazy. And because half the reason that people don't make any progress and what they're working on is because they're trying to focus on too many different things at a time. They start working on little fragments of each different problem, but they never actually solve any of them because they never made any organized progress toward any one goal. And so this question so this card sorting can actually help prioritize both the library staff and user patrons themselves. And so if I go back and forth between users patrons and customers because each different organization that I pulled from uses different terminology. There's no consistency that's okay. Can't decide. And question tracking some libraries already do. And some libraries are looking at different ways to do it. Who is going into the library itself who is calling in who's emailing in. And what are what do they need. What are they actually asking, and is what they asked what they actually needed, or was it required for the reference interview to be able to win out what they actually needed. And because if I when I worked in libraries that was half of what I did, it was people came in with a question. But then when you start asking for additional information you realize that their question is maybe not what they actually needed. They may have come in asking for. They want to learn more about the American job center. And then so they asked about that but then you find out that they actually need unemployment forms and assistance with a resume and cover letter. And maybe the American job center is the best place for that, but maybe not. And maybe based on what they are trying to accomplish. And once you help them articulate and write down their actual goal and start breaking it down into subtopics. And then you realize, oh, maybe that's not actually what I needed. Thanks. And that's kind of, if you've ever worked behind the ref desk at a library you probably run into that already. That's reference interview. Yep, that's that skill. We know you really don't want what you say but let's get there. Right. When dealing with tech you run into this a lot just because people don't always understand what the tech is available. So when you start putting together the menu of technology and just having that on hand for yourself and library staff. And that menu that you start building up is how you're going to help people play matching. There because there's a bunch of different routes that people are going to come into the library to start presenting the problem that they're trying to solve. But you need to help them format it as a solvable actionable problem. And I think there was a session that I went to recently it was called design your life. And design your life came out of Stanford. It was a TED talk. And he talked about find the actionable problem versus the gravity problem. The gravity problem is the problem that you've been working on forever in a day. It's the one that your friend comes in and complains about 8 million and one times but they never do anything about it. And it's either because they can't find a solution or because they can't get motivation to do it and they're just never going to do it. And there's your gravity problem. Avoid the gravity problem otherwise you're going to get pulled down. And I'll actually put in the link to that TED talk to just because it was delightful. And I will open this on the other screen so that there is five steps to designing the life you want. And I will put that into the chat. So really good talk. There's also a book about it. Check your local library. And so really what libraries are looking at is this is a thing they do already but how can you format it to help best with the guiding design when you're building library services. So the most common way that libraries are doing this right now is by is by just building metrics. So another way that you can do it is by starting to pull out keywords within emails and pull out keywords within conversations and start building a visual map of those keywords. When you build a visual map of those keywords then you'll actually see which blob is bigger. And the colors in that visual map will start to like pull information out better. So you can start question matching metrics into a data visualization. And you'll be able to interpret and use the information more effectively.  There's also word mapping. So if you turn question tracking into a word map. A lot of the tools that are out there the words that are most important will turn bigger. So the more people who say that term. The word just turns giant. So you know just visually and also word map library. It just goes together. And. Oh, I'm actually going to drop this down here. And this is kind of a funny side note but on the on the second monitor that I have I have the picture of Christa and me on the webcam. And the video that I just pulled up the guy was like had his arms outstretched. So it looked like Christ his head would just randomly plopped onto his body. I was kind of awesome. It was lined up perfectly. Yeah. And so also go down into. So these are the resources that you use to pull out the information from people but now you need to start formatting it in a way that you can actually use with library staff or on your own if you are a solo librarian or on your own in this. So that is the guide design overview is how you just hold all this information from about five or two, three, four or five different resources. You might have collected it in one week in one month or over a course of a year. And now you need to pull it together. So it's usable. So this is the guide the design overview is how do you actually use this stuff. So I categorize this into two different segments. One is the resources that will guide the design process itself. These are the resources that help ground you into the whole human, who people are what are they motivated by what are they focused on what makes them do the things they do. And then the narrowing focus is how do you actually how do you map this stuff for library staff. How do you brainstorm it. How do you organize the information so that everyone on your library staff actually understands what people are facing and that you have more eyes who are contributing to a solution. How do you format this so that people understand the problem and can help. So the guiding design resources and one of the most common ones that's used in user experience design and product design is the persona. So I also have a worksheet for this again frog sitting haven't gotten it on there yet. But the persona is, it's like a little sheet, and I'll pull it. Oh, I can't pull up my canva because I can't remember the password because it's stored on my local computer. That sounds familiar. I'll actually if I open up canva I'm going to open up his canva. No, let's not do that. That's okay. Yeah. Sorry. It's basically what I can do is pull up the UX sheet. So you can actually mentioned everybody's here. We are getting close to 11 o'clock but that's okay. We do not cut things off just because we hit 11am. If you have any questions type in the question section if you want me to unmute you, let me know and we can do that. And you can ask your question or make your comment that way. We'll stay on as long as made I cease to finish things up and if people do have any questions. Alright, so I will drag this over. I hit a shortcut key on his he has an ergonomic mouse and I keep hitting the back button. That's on the side of the mouse. And that is what I just did. So I will open this again. These are just templates that you can fill in. You can download them. Basically, if you look up a persona of a template of a persona. There's a bunch of different flavors of it, but it has the same general categories. So what are people actually facing what motivates them to do the things they do. Who are the people surrounding them that are helping influence and impact their decisions. What are their life goals. What are they actually prioritizing what are they taking action on right now and what's kind of generally taking a backseat. What are the barriers that are getting in the way of their actual goals. I added a few more segments into my into the one that I actually customized. I added a tech segment. Just because I wanted to find out which technology people already use because if you already use a technology just start adapting that technology to suit the new goal that you have. And kind of a summary segment and the target demographic that they would fall into in your specific library. You can also use to categorize and use different terminology for how they categorize people. But so back here. I'll just feature a couple other one of these. When you challenge people to tell another person's story. That's kind of the ultimate and empathy and the ultimate and getting into someone else's shoes. So if you write someone else's story and then trade stories and figure out did I actually succeed in getting into another person shoes. And there's also this is another one that isn't really UX related but it's just library related is building an inspiration board or a collage. That has different images art books quotes keywords that are just related to that demographic that when you look at it. That's that they say this is who this person is this is who they're all about. And it'll ground you into making decisions based on who people actually are. Your brainstorming that's a good idea so you remember and then modify it as you change and learn new things. Exactly. And it can be done virtually or in a physical board. You can get a piece of poster board and put it together in the actual library, or you can use like Google Docs or use any shared document board canva you can use and just put it together like that. And so I'll just touch on a couple of the tools that you can use to narrow focus and start the brainstorming process. The quickest easiest cheapest way is using the post it brainstorming. It's basically putting together a general topic on the on a post it and then start branching out using other post it's related topics. Once you've brain dumped everything as a individual or a group, organize it and start clustering it and find out what matches a similar technique is mind mapping. Mind mapping. There's another Ted talk that actually shows how to do it. There's other books that do it. There's about a million different PhDs that do it.  Miro is a free tool that you can use to do this digitally it's M I R O and it has a mind mapping template that's already made up that you can just fill in. But you start off with the topic and instead of post it's you just start building physical branches. These physical branches can then be connected and reconnected so that you can start uncovering patterns in the category that you're talking about. So you might start off with a demographic and the branches might be the problems that people are facing, or you might start off with an actual problem and find out the demographics or the sub problems that are within that problem. So there's different routes that you can do this, but the tools are free. And asset mapping is figuring out what you're good at and why, because you might be choosing what to focus on based on what library staff and available resources are focused on. Because it's going to be kind of hard to actually do any of this if you don't have people that are willing to try it in the actual library. So it is 11 or three, I kind of whipped through the last little bit of it, but we got there. And so I will be reformatting this to make it more UX friendly. Right now this isn't a list format, but if you go up here. There is a if you you can actually see a visual difference between the card format and the list format. And you can see like even just looking comparing the two side by side your brain processes the information differently in the clean card format, then it does in the list format. To me it feels less overwhelming. Individual concepts. And I can focus on each one rather than all this long list and which thing do I want. Do I have to look at next. Yeah. And blocks of text to instead of the blocks of text are okay, but you can add a picture on the right hand side to break up that block of text. And then the brain is able to process the information more easily and group and categorize and remember the information more easily. And so that's why textbooks do what they do a lot is they will add a little related picture on the right hand side, and then add more white space and then add a color blocking system. So that different concepts are color blocked out so that you can visually block off that design. And so that is why in here it's more visually spaced out for this digital literacy guidebook and the concepts are actually blocked out. And so that is just switching it out that way. This is the almost the exact same layout as I did with this. But it uses color blocking. And just that little thing takes like 30 seconds, but it makes a big difference. Admittedly, I could use more pictures on this, but yeah, we'll get there. So that is the evolution of design. Were there any questions about what was covered. It was a lot. But like I said, you know, this is just a start. Yeah, if anybody has any questions, go ahead and type in the questions section. Nobody typed in anything during the session, but that's okay. As he said, there's a lot. Okay. Mo, I see raised your hand you have a I've unmuted you do you have a question. No, oh, okay. No problem. Probably tap the button or something. Okay. I will sit my coffee. Well, if nobody has any questions, that's okay. This is, you know, as we said, this is the first of our four part series on this teaching technology and the beginning of this course to so I'm an intro to the beginning of this course. That's all right. Yeah. So, this is just to get you started as anybody. We just have some thanks Moses. Thank you. Thank you so much for the session. It doesn't look like anybody has any desperate questions they need answered right now. They never do. Yeah, that's all right. To take in right now but that's why we've got, you know, this is just a start. So, yeah. Anything else you want to wrap up with this before I go on and talk about what we're going to be doing next. They've heard enough. It's 1108 they've heard enough. I'm going to pull presenter control back to my screen here. Go. All right. So, as we said, this is part one of this four part series. The other sessions will be coming up over the next couple of months they're every other week ish with other things in between. So, in as it says here the course content will become available at the start of each of these intro sessions so right now I've got the overview, and as I said she's going to with frog sitting, working on that, getting that updated. So we can have the frog have a do a little cameo. They're nocturnal so I don't know if you'd like that little red eyed tree frog. Let's not do that. No let's not wake them up okay. And you can go ahead and register for the other three sessions coming up session two three and four they're up there and posted and got links to them. I'm session two for this teaching tech is on June 16 session three finding partners and preparing staff is on July 14 and the last session marketing and follow up will be on July 28. So if you want to go ahead and register for the full series of all of those and then work on the course work. As it says here, the course anyone can take this course this is not something specific to Nebraska, which is great. But of course, we will see credit for our Nebraska library certification we can only issue that to our Nebraska libraries. If you do have a, you earn CE credits for anything at yours in your state, you just have to reach out to your CE granting person, and show them this course, the actual course work and see if they would, how you would get see from your own state. And there's a link here which we did share to the chap it's a link here right into the preview that Amanda was showing. So, you got that right there and as each of the other sessions come live they will be added to their session descriptions as well. So that is rapid today show and some intro about our sessions here you can see the next couple of months of our scheduled sessions encompass live. We do have our archives right here I mentioned that if you click on right underneath our upcoming shows the link to our archives is all of our archives most recent ones to be at the top of the page. So today show be right here at the top should be done, as long as go to webinar and YouTube cooperate with me by the end of the day tomorrow at the very latest. And I'll post it here with a link to Amanda slides. Everyone who attended today and registered for today's come session will get a email from me. And letting you know that it's available. We also have a Facebook page you can see that it's been linked in many of our pages. We do post things over there as well. So if you do like to use Facebook. Here's reminder for today's show info about our speakers when last week's recording was made available. If you do like to use Facebook, give us like over there we also post to other social media Twitter, Instagram, that we have using the hashtag and come live a little abbreviation so if you want to follow what we are doing on other very social media you can use that hashtag. Or you can just keep an eye on our website. While we're here in the archives I will just mention there is a search feature here so you can search our archives for any topics you might be interested in see if we've been done a show on it. You can search the full archives or just the most recent 12 months if you want something really recent. That is because this is the full archives for encompass live I'm not going to scroll all the way to the bottom but just to show you that encompass live premiered in January 2009. 10 years 1011 12 years worth of recordings here. So, just pay attention to the original broadcast date of anything that you watch on here. So you know that that was done at that time. Information may change over time. Some resources may become outdated or are some things will stand the test of time like some reading lists maybe and other things, but some things may not. Links may no longer work anymore resources may change drastically from when we had original show that some websites are prior services may no longer exist at all. So just pay attention to the original broadcast date when you do watch any of our archives. We will, as long as we have a place to keep them but we will always keep all these up we're librarians that's one of the things we do is host archive and historical documents. And that's something we'll always have our full archives here for everyone to watch if you if you want to. Let's go back to our main page here. So that will wrap up today. Next week we'll be talking about a mental maintenance. Jeremy Balm who's from the Lincoln Louisiana parish library is going to talk to us about mindfulness and self care. We can do that as in our lives, and that may also help something we can share out to our patrons as well. So please do sign up for that show or any of our other upcoming shows we have definitely. If you want to keep going with this series or other part two, three and four get registered for those as well. And that that wraps up today show. Thank you everybody for being here this morning. Thank you Amanda and Optimus the frog Optimus prime. Yes. Green to let Amanda join us here today. Hopefully we didn't disturb his sleep time. Yeah, he's fine. And we will see you all on a future episode of encompass live. Bye bye.


Hello, everyone. Welcome to Kupan. My name is Purvi. Hi. I work at Honeycomb. I've worked with browsers for a really large part of my career, and I'm really interested in getting front-end observability to a standard that's on par with the kind of observability we have for backend systems today. As I mentioned, I work at Honeycomb where we're trying to solve this problem, and I'm going to prove her on the OpenTelemetry.js project with special interest in web APIs, and I'm really excited to talk about OpenTelemetry and browser performance today. So I want to start by getting to us, getting us to a common understanding of what I mean by web performance, because it can mean a lot of different things to a lot of different people. As devs, I think sometimes we try to make things as fast as possible, and honestly, that's really fun. It is a really fun engineering problem to make things fast and performant, and we kind of end up convincing the execs by saying something like, improving our page load times will get us increased conversions, and, you know, execs like money. So it's a good argument, but it's honestly pretty hard to correlate that, or I guess, cause that directly with data. So when I'm talking about performance on the web today, I'm more interested in if the users of those websites think that that website is performant. It's a much more accurate indicator of how your website is going to be used and whether your website is easy to use based on what users think more than what your page load metrics might say. Because ultimately, and this is from the MDN docs, which are kind of the main browser source of documentation, web performance is really all about making websites fast, but that also includes making slow processes seem fast to users. And that's a really important distinction. That perceived performance is really, really important. So what are our web performance goals? Before we get into what we measure and how we measure things, I think it helps to think about what components make up a performant web page. And that definitely includes reducing our overall load time, but it also includes making the site usable as soon as possible. Are people actually able to carry out the interactions that they expect to after the page has loaded without getting frustrated? Is the site reliable and pleasant to use? Are things moving all over the page? Can I get a show of hands if you've ever used a website that has really annoyed you to no end? Yes. We're all users of the web, and when we're trying to carry out critical things like checking into a flight or accessing some government services, it's really important to have a reliable website. And that also part of web performance should be responding and reassuring users when they're taking action. So you might not always be able to make your backend processes fast enough to have like near instantaneous feedback, but you can respond and reassure users as they're taking actions. Because using the web is no longer optional, especially since the pandemic, more and more of our critical services are accessed online. Things like getting vaccine appointments or changing your address in other government services. It's our job as developers to create reliable web performance experiences for our users. So let's get into some common performance metrics that are interesting. So the number one thing that comes to mind is your page load. But the problem with measuring page load times is the way page load is measured can vary a lot. And it can vary depending on who your provider is for what you're measuring, whether that's Google Analytics or a real user monitoring tool. Every tool might do it under the hood a little bit differently. Some tools will define it as when the DOM content loaded event has fired. So this event's fired when the HTML document has been completely parsed and all deferred scripts have been downloaded and executed. But it doesn't account for things like images or async scripts and what happens after that initial page load. Also it's pretty common to have it when the onload event listener has fired. And we commonly hear that improving page load times improves conversions, but usually that's taken a little bit out of context. Even after the onload event has fired, the page itself might have been painted, but there's other things that make it usable. So it's still a frustrating experience as a user to see a page loaded and you're trying to tap a button, but it's not doing anything. So that results in a lot of rage clicking. And all these metrics don't really matter if users aren't happy. So nothing, like if you improve your page load speed but users are still frustrated, those metrics aren't that important. Then we have core web vitals. So core web vitals is initiative by Google to provide unified guidance for quality signals that are important to delivering great user experiences on the web. So they kind of had this initiative that developers shouldn't have to be web performance experts. So we're gonna come up with these common metrics that Google thinks kind of encapsulate good user experiences by talking about load times with largest contentful paint, interactivity with first input delay, and visual stability with cumulative layout shift. And we're gonna get into all of these, but just a quick note about first input delay. It's currently a metric that's going to be deprecated and replaced by the interaction to next paint coming in May 2024. So first input delay really only accounted for a user's first interaction after a page is loaded, but interaction to next paint is intended to kind of be a cumulative score of how interactions continue as a user is continuing to use a webpage. So I wanna get into each of these metrics because I do think it's important that how things are measured corresponds to the value of insight that you get from that measurement. So for largest contentful paint, the way that it's defined is the render time of the largest thing in a webpage viewport. The viewport's like your browser or mobile browser screen. And the largest thing in it. So that might be an image. So here's a couple of examples. So in the top examples, you can see this is a TechCrunch website. And under the hood, it's trying to figure out, okay, when do I fire my largest contentful paint event? And it's when I see in the viewport whatever the largest thing is. And that happens when the image on the right-hand side loads. But the more interesting example is this Instagram example. So for the Instagram login page, we see that the LCP actually fires after the logo has loaded, but that login button hasn't loaded. And I don't know about you, but I think that login button is pretty critical to considering the main content of that page to have been loaded. So I'm actually kind of getting a bit of a false metric there by just seeing that the logo has loaded. But ideally I would like to be able to define whatever I think the main content of the page is. And one thing that we start to see pop up even more and more as an issue with largest contentful paint is ever since we've had a mandate now, which is a really good thing, to have cookie banners on our websites. A lot of folks are actually seeing that the element that Google considers your largest contentful paint is not the thing you expect, but it's actually the cookie banner. So you're getting a lot of LCP data values that are false because they're measuring whenever your cookie banner is loaded. And often cookie banners are loaded by third-party websites, so you actually might have really, really skewed data. So I have a lot of beef with LCP because not only is this stuff that we talked about, but also the values that are defined as good, needs improvement, and poor are based on studies from the early 2000s, back when the web was solidly in its neopets era, if you know, you know. And all of these studies that are cited they were conducted on really small sample sizes of like 100 or 200 undergrads that all went to the same university. So that's really not relevant to the modern web today. We run a lot more JavaScript. Like React apps are so bloated these days, we're running so much more, and none of these tools existed in the early 2000s. And most importantly, the main content of a page is usually more than any single element. So moving on to cumulative layout shift. So again, show of hands. Who has used like a recipe website and they're trying to get to the recipe?  Like can I just get this done? And that's kind of what cumulative layout shift really is trying to measure. It's trying to measure essentially how annoying is this website? How much are things shifting and putting things out of view? It's actually really like this metric, but there's a little bit of a problem with it. For a really basic use case, it does a good job. So if you have some content that then gets shifted down, it'll do some math and we won't get into it because it's really not that important. But it does some math to figure out what percentage of the viewport combined with some other things to give you a layout shift score. For a more complicated example like this one, where several things might be shifting, so you can see that dog gets pushed down one, horse gets pushed down two and then zebra actually gets pushed down like four little things. cumulative layout shift, it used to do an amazing thing. It used to combine all of these shifts and report them as an aggregated value and they changed that. So now they actually only pick the largest shift that happened. This results in some pretty weird behavior because you might see a large layout shift score and fix that issue, but then you might still see something that's almost as large and have to keep fixing it. So it kind of feels like whack-a-mole. So what we're really talking about is the largest layout shift. And that word cumulative, which was so amazing and powerful, is actually not really describing what this is measuring. So it can kind of, when you're trying to fix a shift score, sometimes feels like playing whack-a-mole because you don't know what's going to pop up and you don't know how you can keep improving things because it's not really cumulative. So as I mentioned, first input delay is being sunset because it is possible to have a pretty good FID score even if the responsiveness. And when I talk about responsiveness, I'm not talking about sort of like view port size. I'm talking about you try to interact with a button and then nothing happens and then you get really, really angry. So it can really lead to misleading data about interactiveness because it only measures the first delay and you usually end up loading a lot of JavaScript that can block the main thread later as well. So interaction to next paint is exciting. I'm really excited about this metric because it is an aggregate metric that continues to measure how interactive your website is. And that's coming May 2024. It's available to use now in beta as well, but it is going to officially replace FID as a core web vital in May of next year. Okay, so that was a lot. I said a lot of acronyms. I said a lot of values.  This is a picture of my dog. So she's the donkey on the left and her two best friends. And they dressed up for Halloween. It was very cute. My partner and I like to joke about this picture that if they were the three pillars of observability, Misha would definitely be metrics because she's kind of weirdly shaped and odd. So yeah, I just want to take a minute, reset our brains and get into what these metrics end up leaving out. So often these are just, these are sort of like the only things that we end up measuring on the web. And we kind of try to gain these metrics as much as we can and determine whether or not our site is performant or not. But they leave out a lot. They really leave out how network requests are affecting page performance because websites don't exist by themselves. They're calling so many different APIs and services and it's important to have insight into those too and how that's affecting web performance. They leave out anything more specific about your particular use case. There's so many different types of apps and websites and we try to hold them all to a certain set of metrics and a certain set of standards, but they're all really, really different and we should treat them differently. And for me, most importantly, as a developer, I get frustrated because this really leaves out any clues about what to do next. It's hard to know what to do next because all you can see is that your metric needs improvement or even more frustratingly that it's in the poor category, but there's no clues for how to improve it or what to do next. So that kind of brings us to the question, what should we measure? And spoiler alert, it depends. It depends a lot and we'll get into it because context is everything. The context of your website or application is really important to determine what your web performance goals are. And I kind of think of it in two categories. One is, what does performance mean for you? So the first question to ask is, do we care about search rankings? And the answer might be yes. If you're an e-commerce site or a marketing website and there's so many more use cases where you do care about search rankings and performance in that way, you do care about those absolute values that Google has set and those might be your baselines. But for a lot of us, if that isn't you, consider setting different performance baselines. If you don't care about page rankings, those absolute measures probably can be a little bit different. There's research that shows that users can be bucketed into familiar users and unfamiliar users of your app. So let's say if you're building an app that people use for work, they might be more familiar with it because they come to it every single day and they will probably be a little bit more tolerant of load times. And when you're building web applications, it's sometimes not realistic to hold yourself to a sub-2-second page load. But you can give users a lot of support and feedback to be able to wait for the things and give them responsive feedback and be like, hey, we see you. You're waiting for things and the things are coming. So for the case of familiar users, they might be a lot more patient than you think. Unfamiliar users, on the other hand, might be a lot more impatient than you think. So your web performance standards might need to be even higher. Is your app heavily used by mobile web users? This is super important context to have because performance on desktops and performance on mobile web browsers are two completely different experiences and they should be treated as such. Mobile phones still don't have the browser processing speeds that desktops do. So it's important when you do have your web performance data to be able to compare apples to apples and separate out your data from desktop to mobile browsers. And then what are the critical actions that users take in your app or website? Are those things performant?  And there's dozens of other questions. These are just some that came to mind to ask yourself. But the point I'm trying to make here is that it's important to ask yourself these questions to figure out what performance means to you. The second piece of context is what information do I need to add to my telemetry to make sure I can debug it further? Seeing raw values can be really, really unnerving. And I want to kind of go from that no idea cliffery to being able to debug things like this person who I found out is not Julia Roberts while I was doing this talk. Yeah, big surprise. So things like your user ID and session ID to be able to really dig in to see, okay. So I have this particular user who's been talking about performance issues for so long but I can't actually see any data from their sessions. Element target information. Which element actually caused my cumulative layout shift score? URLs, what pages are my... If I can segment out and see, is my checkout page performance? Maybe I don't care so much about some other pages but I really, really want my checkout page to be performant. Browser metadata, device data, browser data, whether your site is being accessed on mobile or desktop. And lots more. You know your system best and you should be able to add whatever information you want to do the type of intersectional analysis that gets you to be able to go from I have a problem to I can debug my problem. So I just want to quickly talk about field data versus lab data. So there's kind of two ways to measure things on the web and one is synthetically. So that's known as lab data. So that's your running some sort of synthetic system. You can run Google Lighthouse against your website and it's like a bot goes and hits your websites and reports back a Google Lighthouse score. You can run that in CI. There's even automated synthetics tools. And it's still a really useful thing to be able to have synthetic data but they're usually single data points that are generated by bots and they can be misleading because they might not be where your users are and they might not be using the devices that your users are using. So sometimes you'll get like a skewed idea of your performance if you're only using synthetics which is really important to use field data or real user data. Part of those core web vitals is not just seeing that one of your users had a page load time under two seconds. You actually what the core web vitals quote is that you want to have a sub two second load time for 75% of your users. That is actually... So to be able to get statistical significance you need to be measuring with real users because this actually ends up representing what actual users are experiencing. And then you can drill down and look at different percentiles as well. What is the slowest that some of my users are experiencing? What's in common about them? Are they at a particular location or accessing it with particular devices? So this really goes into being able to do that intersectional analysis and making your website faster for real users. So one way to measure data with real users is by using open telemetry. Open telemetry is an open standard for collecting and sending data. And they have a browser SDK. This is an open standard. It's really flexible. You can send it to your vendor of choice like Honeycomb. There's also an open source place you can send your data to called Yeager. And all you need to get started with open telemetry is a browser or website, the open telemetry APIs. And like I said, a backend that accepts open telemetry data. Because I don't think vendors should be able to determine what you can measure. You should be in charge of the telemetry that your system is sending. And if you want to make changes to that, you should have the power to do it rather than having to make requests to vendors. And because it's open source, you can actually contribute the instrumentation that you think is missing to measure your system better or add the data in that you want. So getting started with open telemetry, I really don't have a lot to say about these next two slides. You install some packages. You write the setup code. Don't feel like you have to take pictures of these. I have references at the end. And with an example GitHub project of this setup. But yeah, it is as simple as you install some packages. You add a little bit of boilerplate setup code. And you're ready to start sending data with open telemetry. This is kind of what adding context looks like in open telemetry. So those things that we talked about of adding the user region, adding the browser language that the user is using, or whatever else you can add, your user ID, session ID, things like that. So that would be added on your resource attributes that get sent with every single span to open telemetry to allow you to do better intersectional analysis. There's some auto instrumentation that comes along with the setup code. And one of them is document load instrumentation. And I know what you're thinking. I spent a long time talking about how page load instrumentation or page load information isn't that reliable. But for me, the most exciting part about the document load instrumentation is actually the insight that it gives you into the resources that are being loaded onto your page. So this now goes from, okay, my page load is a little bit iffy, but I can actually start debugging it with figure it'll show you like the order that your resources were loaded in and how long each of those resources took to load. So here you can see this is a trace from our documentation website. And there's a gif here in our bubble up documentation that takes six seconds to load. So it's probably a good idea for us to go and maybe compress that down or use a different asset for that. And you can really see that at a glance. So it's really exciting to be able to immediately go and start debugging what's going on. The other piece of auto instrumentation, and when I say auto instrumentation, I mean, along with your setup code for open telemetry, it'll just start sending these fans. You can set up network auto instrumentation. So this will pick up and sends fans for each of the network requests the browser is making. And you can set it up so that it'll propagate what's called a trace parent ID. And if you're already instrumenting your back end with open telemetry, it'll connect those traces kind of like you see in this trace here where this HTTP get trace was actually made by the browser and it connects to your back end traces. So front end teams often encounter this thing where they're actually the first folks to have bugs kind of come up for them. It'll be like, hey, your website is broken. There's this bug. And the first thing they want to figure out is it our front end or is it something going on on the back end? And kind of jokingly call that proving your mean time to innocence. So something like this will prove your mean time to innocence pretty fast. You can kind of see at a glance, is it your back end that's taking a long time or do you actually have a front end performance issue going on here? There's also some early Web Vitals instrumentation that's available. It's linked in along with that GitHub repo I was talking about. And it's based on the Web Vitals NPM package attribution build. So that attribution build is super, super important because not only does it report your Web Vitals scores, it actually tells you which elements it attributed those values to. So what I mean by that is here, I have an example of like some cumulative layout shift scores, but it'll actually tell you which target in the DOM contributed to that CLS score. So now you actually have a place to start to go and start debugging, which is pretty powerful. It can tell you things like which element it considered to be the element that it based the LCP score of. So you can do things like discard, or discard any events that you feel if they use the cookie banner as the LCP. So you could actually just totally ignore those and get much better LCP scores by having this attribution to what caused it. So I think this is a key piece because often Web Vitals are really, really hard to debug. And being able to have a jumping off point makes it a lot easier. But in my opinion, even more exciting, and this is now getting into some manual instrumentation, is the Element Timing API. So this is experimental currently and only available in Chromium browsers, but I think it's still pretty useful to try and try it out on your website. So basically it's a new API that allows you to determine what you think the main content of your page is. So for example, you can just put this Element Timing attribute on your HTML, give it a name, and in JavaScript you can observe and check in on how long that took.  So you can go from LCP to time to first tweet if you're building Twitter or X or whatever it is today. But it just means that you can get a much more meaningful metric. And then there is just more manual instrumentation. So you can wrap your JavaScript functions in spans and send them off with open telemetry. So if you find that there's, maybe you looked at some long task stuff in the browser and you identified some places that are creating long tasks, you can then wrap those functions in open telemetry spans, send them off, and be able to figure out which parts of your functions are taking longer than others and break them up. And there's lots more. There's long task auto instrumentation. So that'll actually do some auto instrumentation on what's blocking the main thread for your JavaScript. There's user interaction auto instrumentation, and it's really useful to link that together. So that'll be like clicks, scrolls, basically anything you can think of as a web event, you can track it with user interaction auto instrumentation. There's a new long animation frame API, which is more exciting than long task auto instrumentation because it actually takes into account animation frames over just what's happening and being executed in your JavaScript. This is super experimental right now, but I'm excited to play around with it, and also whatever else you can think of. Open telemetry for web SDKs is still pretty much, it's a pretty new project, and we're really trying to make it as rich of an experience as possible. So if you're interested in getting involved, the Open Telemetry client side special interest group would love to have you there. So to recap, we talked about how things are measured is really important to the insight that you get from it because LCP values, for example, might not be that interesting to you if they're measuring a cookie banner rather than the main content of your website. So it's important when you're using these automatic measures to understand what is actually being measured and whether that's useful. Your context is the most important thing when it comes to deciding what to measure. Measuring with real users is important so that we can do that intersectional analysis and figure out what issues are going on for what segments of your users, and adding detail to telemetry is super, super important. That's all I got. Thank you so much. I think we have some time for questions. Yeah. If you have questions, please come to the mic. You mentioned about adding additional tracing to be able to correlate front-end events with back-end systems. Can you elaborate a little bit more about your experience? That's probably the biggest reason I'm at this conference is to learn how to do that. Oh, sure. Yeah. So if you're doing it, there's a couple ways to do it. You can do it, like I said, using the Open Telemetry Network Auto Instrumentation. There's two packages. One is if your front-end sends data over XML or if your front-end sends data with fetch APIs, so use whichever one your front-end is using. And then there's actually an option within that to tell it which... You can give it a regex to match your back-end API URLs, and it'll do some context propagation. So it'll actually just send a header. And if you've already instrumented your back-end systems with Open Telemetry as well, it'll connect that trace parent header to your back-end telemetry. Yeah, absolutely. Hey, how's it going? Great talk. I had two questions, actually. So I'm gonna pick this up because it's a little... So the first question is around sampling, right? Because in situations where you have millions of users and tons of apps, you likely don't want to have tracing on by default trying to calculate everything, right? Yeah. So what are your thoughts on potentially sampling at the browser and how to do it in a smarter manner as opposed to random sampling? And the second question was essentially around updates to the client-rum SIG for Open Telemetry because I don't know if it's gotten a lot of traction, but there seems to be a couple different projects in this area like Grafana Faro and a couple... I think Boomerang's one, but there isn't a lot of standardization around sort of that data yet, the schemas. Yeah, so I'll start with the first question about sampling, and that's a great question. I feel like because all of this is still in a bit of an experimental stage, there hasn't been a lot of thought behind that. So right now the sampling available through Hotel is you can give it sample rates, you can do tail sampling through the collector. At Honeycomb we have a thing called refinery where you can actually add lots of really... you can add dynamic sampling rules or do rule-based sampling as well. In terms of sampling on the front end, it's a little bit different because you're probably going to get so many more events and so there's kind of two things there. There's your network requests that get connected to your back-end traces. So you probably want to sample those... you want to be able to connect those and sample them together because otherwise you'll have a bunch of disconnected traces. In terms of other things that may not connect to your back-end, some sort of rule-based sampling would probably be a good way to go. And the second question was about the client-side special interest group with open telemetry. So we do have a client-side special interest group. We meet every Tuesday. In my references link, there's a link to all of the special interest groups and when they meet. So right now one of the things that we're doing as a SIG is trying to align on browser specifications and semantic conventions. So that's something that's an ongoing effort right now to define those things. If you care about that and you want to have a say in that, come and get involved. Yeah, thanks again. Great talk. Yeah, I just kind of wondered, as I've been thinking about this, where you see the intersection is between ROM where we're trying to aggregate things a little bit and then tools like Adobe Analytics where I'm trying to really capture the user's journey throughout the site. And you could model the ladder maybe as traces and spans would be one ridiculously long trace for however long that user is engaged on the site. But it does seem like there's kind of a middle ground here where as a developer, maybe you're doing a Twitch video streaming session and I want to know, you had a problem and I want to look up your session ID which maybe I carry in baggage to the back end and I want to see everything you did. But then it feels like maybe we're overloading ROM to be a user journey capture tool but just kind of wonder what your thoughts are and where you draw that line. That's a great question and I think that really just depends on vendors and what products they want to build and who those products are built for and what problems they should solve. So ROM is really interesting because it aggregates a lot of data for you and it kind of gets you to the point where you know where things are and where problems might be but they're still kind of figuring out in those tools like how can you explore and debug further. So I think in terms of like a data standard open telemetry is unopinionated and really flexible and it can probably service sort of like all of the tools that you mentioned. But I think going from real user monitoring to front-end observability is a leap that we still have to make in terms of like how you can go from sort of more metrics oriented data to actually surfacing unknown. So my answer is like I don't really know if I draw that line and it would be great for front-end devs to be able to explore their data and be able to work closer to how back-end devs get to work today with observability. I think we have time for one more. Or no, okay, we got to wrap it up. Sorry, I'll chat with you afterwards. Okay, thank you so much.


The randomized clinical trial is a study in which the participants are divided by chance into separate groups that compare different treatments to other interventions.


Hey, what's up y'all if you're like me you've had your shared relationships with people and Friends so-called friends or whatever that you thought at one time Y'all were good, and then the next thing you know you may have been betrayed by them They may have done you wrong But here's my question when I ask you which one is worse of which one would you have to have? If you had to choose between one of the two Which one is worse a fake friend? Or an enemy Which one in your life has done you the worst or that you would consider to be somebody That you would be able to deal with versus the one you could not deal with My take on it will be a fake friend a fake friend be somebody would be worse to be a deal with because I wouldn't be expecting And be faking to betray me an enemy Somebody like that. I would expect that but let me know what you think in the comments below. I'm trying to see something