Jared Spool: Welcome, everyone, to another episode of SpoolCast. I am excited today because I get to talk to my good friend, Nathan Curtis from Eight Shapes. He is going to be presenting at the User Interface 15 Conference, November 8th through 10th. He's doing his workshop on standards, reuse, consistency, and libraries.

It's a fabulous, fabulous full day workshop that talks about how you actually think about growing your user experience practice by creating libraries of components and elements that you can reuse that help you keep your look and feel consistent. And helps you grow the things you can do with all the people you're doing it with across your organization. We're going to talk a little bit today about just that. Nathan, welcome.

Nathan Curtis: Hi, Jared. How are you?
Jared: I'm doing great. I'm doing great. So, I've been thinking about this reuse thing. I talk to a lot of teams who are just in the process of maybe they're start ups, or they're working on a project for the first time, or they're endeavoring in something new.

And they have this nagging feeling that they should be doing something to prepare for the future. But of course, they're neck deep in the present. They're thinking about the first deliverables they have to get out and what this design could be like. And all the grandeur and wonderful ideas that are coming out of everything.

But there's some point where you transition from thinking about what are we doing now, and how are we going to maintain this thing, and how are we going to keep it consistent, and how are we going to grow it in the future? Is there a process that people go through in terms of maturing in their thinking about patterns and components in the libraries that they would build of those things?

Nathan: I think so. There's really this sense that reuse and these patterns that arise in the project that really happen on a very personal level first. Every designer sort of starts maybe with a blank canvas in front of them. And they start to design a screen.

They start to design what the user is going to see and what they're going to interact with. And so as they throw all these different pieces or elements on that page, so to speak, you've got a header, and footer, and search box, and all of this other content, there's not really any reuse taking place on that single screen design.

But on a personal level and on an individual level, it's when they start that second screen when actually reuse can really start to happen. Because even within our own design files, you might have one page you're designing, say, for a product list. Another page that you're designing for an actual product detail page itself. Both pages use a header.

Both pages use that really sort of basic legal footer at the bottom of it. And even within that process that you're going through as an individual designer, you'll have those occurrences of reuse. But that's really more of a question of how am I going to leverage my design software to reuse things and to place them in different locations, so that I can manage them centrally. And that's not as complicated a process.

It's really when you start developing the relationships with other people, where communicating what's going to be reused. And then establishing a platform for how you're going to reuse it and change those individual bits over time that matters more. And I think the first conversation that typically happens is between designer and engineer, designer and developer.

Where it's really the designer that's trying to communicate through their own artifacts, be it PDF of wire frames, or even an HTML prototype that they're working on that the engineer's really going to polish up and make production ready. But here's a header that I need to reuse. Here's a sidebar search that we need to have. Or a list of tags, or whatever those different pieces of their design are.

And it's part of that conversation where the reuse needs to get probably more formalized, more intentional, and more documented from that perspective, just as a part of delivering that single project. It's really over that course of a project where things start to stabilize, because in the early portions of a design project, especially creating an entirely new design system of color and typography and so on, everything's really unstable.

But as those designs start to stabilize themselves and really change less and less as you near that delivery to the people that will build the system, then those conversations of reuse start to happen on a project level. Depending on the project's scale, then you really balloon out and start having conversations around, should we really build a library of this stuff that's going to span projects?

Jared: It seems to me that you've got this sort of thinking that's going on in the organization. And I like this idea that this sort of comes out of, you know, you're having this conversation with the people who are going to be developing this thing. And, like, wait a second, we're going to use this a lot. We're going to want to take this and put this in different places.

And we design it so that we can plug it in over here and plug it in over there. Being able to identify that, that seems to be a mark of experience. Being able to have that conversation and talk about it. That's how you know that you've come a long way in your design thinking. It's that you sit and you can identify those things and go, wait a second. This calendar thing? This is going to happen a lot here. We're going to use this everywhere.

Nathan: Yeah. If you really think about a site like one of the big airline sites or Expedia, or something like united.com, you're going to have a calendar picker all over the place. When do I want to travel? When is my trip going to conclude?

And really, that persistence of dates implies date fields, implies calendar pickers, and it implies displays of calendars where you might have some band of time highlighted of the beginning and the end. Those are all different patterns and those can all be instantiated in your own design system as specific chunks of code or a component that you're just going to reuse in different displays.

I think that's also where learning from the design community and all of those existing great designs that we can leverage in our own design projects coming into play, too, because calendar picker is a pretty well known pattern. Even showing a band of dates on a calendar like display is a pretty well known pattern. It doesn't apply to just united.com, it also applies to, say, Google Analytics when I'm doing some analytical tool. Say I want to see results across this period of time.

And so those general sort of solutions that we have to showing dates and bands of times and beginning and ending points, I think comes into play. And you begin to leverage those. But at the same time, that's not necessarily where specific design teams end up investing a lot of their time and saying, "To show a big band of days, here's the global solution that we're always going to use."

More often it's far easier to convince and far easier to leverage chunks of code. And that's why we see that teams invest a lot. And here's the specific chunk of code that we're going to use our date picker. And it's going to function like this when you type in a date in a text field, this extra panel is going to come up. This panel is going to look like this, it's going to have this way to page through months, or show two months at a time. And here's how we've done it. Here's the specific solution that we have.

And on a site like united.com, or Expedia, or Google Analytics, or any sort of application like that, knowing that chunk of code and how it works and being able to package it in a way that not only different engineers across the team can use in their individual pages that they're coding. But different designers or even other stakeholders appreciating how all those things work in evolving their experience is a really important thing.

Jared: So, identifying these components and creating the library to hold them all. Those are like two separate activities, right? You can start by identifying these reusable components and just knowing that they're there. And getting them out there before you invest in some massive library effort. Right?
Nathan: Yeah. Really, the rationale for a library takes on much bigger questions than, do I have a reasonable chunk of code that we're going to spread across a lot of different screens of our design? If it was just that, if it was just one designer communicating with one developer, it might just be conversations around, all right, let's draw a box around the header. Let's make sure that's modular and you can fix that across all the screen designs, and you're done.

The questions about whether you should build a library to reuse things has a lot to do not with necessarily how much is going to be reusable, but how many people are going to reuse it and how do they need to reuse it? Oftentimes libraries come into play when you have more than just a designer and developer talking over a cube wall. Instead, it's three designers that all need to design in a synchronized way or are all contributing different parts to a design system.

It's multiple engineers, it's multiple other stakeholders like product owners or copy writers or whoever it is that's going to come together to work in a synchronized way against this holistic design system. So there's a number of questions that teams need to ask themselves.

Number one, is our experience big enough that we really do have a lot of reusable bits and pieces and parts that we need to codify, not just the actual markup, but guidelines?

Another question is, is our organization ready for a library? Do we have a stable set of people that are all working together and all can come to a common understanding of how things are going to work?

Is our design team ready for a library? There's this question of design freedom and perceived limitations that a library brings to somebody. But can you shift that conversation from limitation to more great starting points to influence the design and how you can embed those library elements into design tools?

And then also is management ready to even support a library? Because libraries aren't free. They take time, and they take an investment of people's attention to make sure that they're solving a project's problems as they're working on them, but they're solving those problems in the context of something larger and decisions that have formulated that design system over time.

So there's lots of questions that teams ask themselves around the experiences of scale, their culture's ability to adapt and investment they're willing to make into different pieces of a library before they really pounce on it and say "All right. Let's do it. Let's move forward. Let's discover this thing." And then to go through the series of steps to actually discover and build the thing.

Jared: This idea t hat libraries aren't free, that intrigues me in that I think a lot of organizations sort of start down this road thinking well what do we do? It's just a wiki right? And you know, we'll just set this thing up and we'll just plug things in there.

It made me think, is a library that's sort of half put together, missing key components, some stuff is out of date, is that actually worse than not going down that road to begin with? Do you get yourself into trouble having a half-assed library? Or is it worth it just starting down that road and getting as far as you can go, and then regrouping and saying hmm, OK this is going to take more resources. But at least we have something,

Nathan: Yes, that's a really important question because ultimately I think the property you're talking about is the library's credibility. You can invest all sorts of time in creating a bunch of code snippets that you think are standardized. You can create this wire frame library that you and other designers are going to use. You can even spend a lot of time investing in different guidelines.

But the moment that somebody engages with your library, say a product owner or a content strategist, and they look at how you codified something and guidelines and the code itself. And they see that the last update date is 18 months old, and you've redesigned the whole site since then. Ultimately, it's not just the library that loses reputation it's your own influence in trying to persist the decisions that everyone has made is diminished. Your influence is diminished.

The question that you asked around is a half-assed library really worth it? Actually I would argue that some of the most important choices that you make around building a library are choosing the right items to put in the library.

People often get intimidated by this sense of well, our design system is really complex. We have 35 different types of pages, let alone all of the components that might go into each of those pages and some of which are reused across pages. That's a lot of stuff. That's like 500 variations of stuff that we have to document now.

The reality is nobody cares about items 400 through 500. They're used so infrequently and their impact to the experience is so minimal that to invest a lot of time writing guidelines around them is foolish. It's a waste of time.

But on the flip side, if you were able to document those top 50 things, or even if your experience of scale was less intimidating at 50, if you document the top five things and you make sure that those most important core components of a page, or most important page types of the experience, or most important grids, or aspect just of your typographic system or your color palette or what have you, all those most important things is where you start. And where you invest the most time to teach people so that they have a good foundation or starting point to jump from.

And in that sense it's not a half-assed library. You've prioritized the right stuff, and you've given your organization the greatest impact that really gain efficiency and consistency and all those other goals that you might have with it.

Jared: So completeness is not the goal is what I'm hearing. But having the right elements in there, the ones that are really going to save people time, are going to create that sort of consistent feel across the design, are going to really be the things that define who you are and what you're about. That's the important piece.
Nathan: Yes. One of the projects we worked on for a couple of years with a large technology client of ours is a component library for their public marketing site. And the library itself, if you looked at the actual card catalog, so to speak, it's honestly a spreadsheet that itemizes each part of the library, might have a few hundred different variations of stuff.

But over the two years, it's almost mind boggling how much we focused on literally 20 of those variations which is actually two or three main components. Think of the big billboard at the top of a page, where a company makes its positioning statement. It has this impact embedded video within it, it's like a big billboard or what they call a hero.

The company invests so much time in getting those right because it's what the user sees first, it's what the business wants to focus on the most, and it's what is graphically the most powerful and central element of the page layout. If you looked at a pie chart of investment in that hero relative to all of the other pieces and parts of that entire marketing website, which are pretty immense, it's almost as if they spent 50 percent of their time on that hero alone.

And that's, I think, a good decision because it's where the rubber meets the road. Where the user makes that leap of understanding of what something is, and then makes a choice as to whether to engage with the company to maybe buy it or learn something more about it. And so hat disproportionate investment is not a bad thing.

Jared: That then says to me that you could budget out a library effort that really just focuses on a couple of important things every few months. Right?

If you just said OK, you know, this is worth it. We got this date spread chooser item. And we're going to use this in a lot of places, we're already using it in a lot of places and we've done it four different ways. Let's combine it. Let's figure out what the best way to do this is. And let's just standardize that and document it. We'll do three other things this quarter. And then next quarter we're going to pick three more things. And the next quarter after that we're going to pick three more things.

And by the end of the year I've got 12 things documented and I've got a manageable library that probably is going to save a lot of people a lot of time if I pick the right items.

Nathan: Yes, and it's that picking process or what often during this process of establishing some sort of design library, the discovery process, of what bits do I need to have in this library, and then ultimately how do I organize and prioritize them, really begins any establishment of a library itself. You don't have a library with all the pieces and parts that go in it.

And during that discovery process you can end up identifying all sorts of stuff, but it's really the attachment of "this is most important, this we should have, this would be a nice to have." And then ultimately you have all those most important things and you need to figure out how much you're going to invest in them.

Think about Yahoo as an example. They've got a slew of different products. They have so many different design teams probably working on a kids' site, a movie site, an auto site. And all of them, you know what, over the last few years, started to converge and realize "Hey, we've got 18 different video players on our site."

So it might be the librarian, this person that's curating this whole collection of reusable bits that identifies that and says "You know what? Header and footer don't really matter because all of these sites are branded in a very specific and different way.

What really matters is how we're showing video across the Yahoo experience and how video impacts the Yahoo brand. So let's develop our video component." Or even all those different aspects of the video experience. Not just the chunk of code that plays the video, but what's it look like when the video loads?

What does it look like when the video is done and tries to forward you to other interesting things? What's it look like if the video goes full screen? What does it look like if the video actually expands like YouTube's video does now from being part of the body to actually take the full width of the page and everything else on the page just gleefully moves out of the way?

All those different choices around how videos operate as a pattern as well as a reasonable chunks occur that people just plop it in their page as a component. That ends up being a really good choice for a librarian to say we're going to focus on these specific parts over the next quarter of the year or six months of the year, because this is the biggest part where Reeves is going to be important and we want to consolidate everybody to be more consistent.

Jared: This almost feels to me like it's too easy. I know it's not too easy. I know there are traps that get us caught up. What are some traps that you see people sort of falling into as they start to build out their thinking around creating components and maybe putting a library together?
Nathan:Most of those traps surround how people collaborate and communicate with each other. One trap is that management, think of it as management of the UX team and the identified librarian who really serves as that advocate, doesn't create what feels like an inclusive environment for people to share ideas and try and standardize this experience together.

But instead takes the stance of: here are the standards. Use them. Don't ask any questions because standards in and of themselves are useless without their ability to evolve with all the problems that teams encounter during projects that are not yet solved by those standards.

Or need to change the standards. I think that openness, that willingness to be inclusive with lots of different perspectives and a very transparent willingness to adapt over time, and show the capability to adapt is going to be really important for the person or the team that's building out these standards.

Another thing the teams need to be really effective at is communicating those standards. There are choices that teams make around well do we build a set of design assets so that our designers are using Adobe InDesign or Omnigraph or whatever those are. Tool choices end up being really important because designers love their tools.

So how do you build and overlay these standards into the tools that people use in a way that's effective and that they are going to be willing to learn how to use them.

Another thing about communicating the standards is building a platform by which you are going to communicate what the standards are and how they are changing over time. You mentioned Wikis earlier.

Wikis are actually awesome. If you have nothing to work with other than being able to distribute PDFs and Zip files of code, a Wiki is a revelation, because it's something that most organizations are willing to stand up for you.

Ultimately, you create one article. As long as you got an eye toward the structure of the site, you just start connecting your core standards home base with all the other articles that describe all the details.

But, and it's a big but, we experienced this with one of our other clients, is we have this explosion of standards communications when we convince them to go from just using PDFs to using a Wiki. But then two months later we hit this very uncomfortable ceiling because suddenly there was this albatross that we couldn't maintain and we couldn't make updates that propagated out to all sorts of pages.

We didn't have all that metadata about what ended up being a pretty large library like where the component code IDs and what categories are each component in and how can we create automated displays of each of the different categories and lists of things so that people can find and learn about these different parts easily.

And suddenly the Wiki turned out to be a great intermediate step but because the company perceived, well we made the investment in our web platform it was something we couldn't down from from there. So establishing a good road map for how to communicate these things and engender conversation and comments and feedback into how the library lives and breathes over time ends up being pretty important.

The more you create barriers to that communication and that open project to standards, projects to standards sort of balancing that you have in your communications then you have to wane a little bit and you influence the library.

Jared: It seems to me that just from everything you're saying that the idea of the library is that it really sort of a thoughtful look at the future. The construction of the library, how you choose to put stuff in it, the way you are going to maintain and curate it over time, the types of things you're going to do, you need to constantly be asking yourself what is it we're going to ask of this thing in the future?

Is that a true statement?

Nathan: I would actually categorically disagree with that statement.
Jared: Oh, really! OK.
Nathan: In a black and white way because ...
Jared: So, where did I get it wrong?
Nathan: To me, establishing a library is the process of recording all the design decisions that you've already made. In a sense it is a historical look back and summary and codification of all those decisions that hopefully your team has made together.

And it is meant to be a platform or a starting point for all of the future design projects to leverage. So it's really not the standards folks that are out front hunting for all those different things they think that the design teams are going to need in the future, say six months or a year from now.

But instead the standards group in effect should be, if you want to think about two people standing together, it's the designer that's in front and it's the standards partner not looking over their shoulder to make sure that they're not doing anything wrong, but looking over their shoulder to try and get a glimpse of how is this design system changing and how do we need to evolve this holistic sense of what the sustainable design is.

So it really needs to be the design and the projects that are the evolving of the experience that's at the forefront in the standards that are recording all those decisions and making all those decisions easy to find and reuse intelligently in additional projects.

I caveat it with, when you spend a lot of time as a standards person trying to envision what the team's going to need, oftentimes what a lot of that investment never gets realized because you end up guessing at the wrong stuff. You don't know the project conditions and you don't know the technology and you don't know the business objectives that the designers are going to encounter on the ground.

Jared: Oh, OK. I see exactly what you're saying now. Basically, as you're choosing your components and stuff what you really want to be doing is looking at what you've done and looking at the paths you've made and the history you've put together.

When you say, OK, what's important, the question that you're asking is what's been important up until now? You start from there. Is that what you're saying?

Nathan: Yeah, because I don't think anyone else is going to trust that some information architect or designer or whoever it is that's one of the lead people curating this collection has some big crystal ball that they have an ear at whatever the CEO is saying about where the company is going to go three years from now.

Most of the time they're a designer themselves or they're participating in all the projects as they happen. So the ability for that librarian or that curator to be able to guess and authoritatively say this is the direction we're going in, that's not the role. I would say that the role of creative directors and those design leaders of the organization are really the people that are setting those goals on the horizon that everybody else begins to converge to.

And the standards person is one of those people that is part of that team.

Jared: How about from the context of the capturing and the packaging of the library itself? Do you need to be thinking in the future as to how are we going to use this? Is a Wiki going to be good enough? Should we be using something that is more data driven?

Should we build something? Do you need to invest a lot there? Or is it the case where you just take the tool that makes the most sense right now and use that until you start to hit the limit and then you figure out how to switch. Because you did say that on that one project that you found that the Wiki that you were using was an albatross.

So I'm wondering how much forward looking you have to be from that perspective.

Nathan:It's in part balancing a trade-off of planning and preparing versus just getting the stuff done. If you're going to build a library and you're going to invest in trying to sustain your design system over time, then you need to treat it like a project.

That project's going to require people to do things. That project may require that you buy software or that you implement web servers or applications on the servers. And so, as opposed to treating the library as this ad. hoc. thing that somebody is doing on the side four hours a week and always gets deprioritized, you need to be more serious about it.

You need to recognize that in order for effectively this product, this standards library to be effective you need to plan. You need to be organized and you need to insure that you've got somebody there that's coordinating the activities or potentially the other contributors that are helping build the thing out.

All of those decisions are part of the planning process, much like you go through project plans for designing the experiences that you are trying to build. That said, oftentimes you make decisions and part of your plan may be this organization isn't stable enough. They're not going to be willing to invest in us building this more sophisticated platform with a lot of different data that we can leverage to communicate the library. They just need something thrown up, because they've got three different vendors working on the same stuff and they just need to communicate out some basic things.

And oftentimes those decisions to build something really quickly are justified. It may just be the reality that, as somebody that's trying to perpetuate this design system using the library, you just go with it. You go with the flow and you get it done.

From a sponsorship perspective, from whoever is paying for these people to create an experience, it's only a much bigger sell for you to say you need to pay to sustain that experience over time. If you've got somebody that's allocating resources, you've really got to make a pitch to say, "We need these people to work on this stuff." And you should expect some push-back or some reluctance of the perceived value of this thing until you prove it.

When you think about planning, it's also think about selling, and think about how you can prototype things or use, honestly, a WordPress blog that has three different page types on it that show "Here's how we're going to relate the components to the library and to the visual standards and so on, " so you can see it. Then you've really positioned yourself as a part of that planning process with a prototype of the library rather than the experience. You can then sell it a lot easier and sell somebody to invest in it over time.

Jared: That's interesting. I hadn't thought about the selling point, but as you were talking about it, it made me think. I was recently reading an article about the designer, whose name is now completely escaping me, who worked originally at IBM and then went on and worked at Mobil and put together their design systems.

You used to pull into a Mobil gas station, and Mobil stations all looked alike. And they were like the first time anybody had ever done that, where the pumps and the signage and the way that the store looked, all the elements had the same sort of color scheme and shapes and rounded corners, and all of those things had been thought through and met these company standards.

And no one had ever done that before this group of designers had started to put all that together. Paul Rand was in the group, but there was somebody else whose name, I am just drawing a complete blank on it, but I'm sure someone will write in and tell me what it was.

Organizations now are used to that. They're used to having a visual-identity kit that they go with. They always use the logo in the same way. They always use their brand elements in the same way. To some extent, you could argue that this is an extension of that, when you start talking about the experience. You could say, well, look, we want to deliver this experience. The experience is very important to our brand. So think of this investment in a library as a way for us to extend those systems that we already have in place for other things.

Nathan: You're absolutely right. A lot of our conversation has been around design standards that user-experience designers typically encounter, and most often it's browser-based applications or other types of digital experiences that we're designing. But that always, especially in the case of very large companies, rolls up into, or maps or needs to be correlated with, a lot of the core brand tenets that a company have that, honestly, the user-experience designer has zero influence over.

But there is this, not just an ecosystem of different types of standards that apply to each other: the brand and visual-identity standards, the online standards, the online component library, and then even things like copy and tone and messaging and all those editorial standards that span not just online but all their different channels.

All those things need to come together in some way, and oftentimes part of your investment as a user-experience designer, in your online channel, for example, ends up being "How am I going to collaborate with these other groups to bring all these things together?"

It's also interesting that I think it points towards, even in an online channel, if you're thinking about your design patterns and your chunks of code as components that you want to standardize on, that also speaks to the fact that you need to make sure you have your foundation correct first.

A lot of that foundation is influenced or starts from things like a visual identity from a brand team. But then that ends up getting formed into things like grids and typography and color and a lot of those different visual tenets that, if they aren't stable or aren't in place, creating a component library that's based on HTML and CSS that relies on all those decisions is sort of a house of cards, because suddenly the sands shift underneath you and the whole library falls apart.

And so that speaks not only to your need to collaborate with all these different standardized elements of how your company delivers an experience to their customers, but also getting the fundamentals right and making sure those fundamentals are aligned across all those different pockets or groups.

Jared: So we've talked about a lot of stuff, just sort of identifying when you might need to start thinking in these ways, and how you get from just having a bunch of components to a library and then maintaining that library and selling it. And you're teaching a workshop at the User Interface 15 Conference, which I'm very excited about: "Standards, Reuse, Consistency, and Libraries." Of the stuff we've talked about, which of those things are you going to go into more detail about in the workshop?
Nathan: Well, we've got a full-day workshop. It's going to be divided into four big chunks. It's a little bit modular, as you might expect.


The first chunk is going to be trying to talk about standards in your organization in general and define a lot of different commonly pursued lines of standards. We'll start and just talk about the culture of standards in the first of four chunks, and then define and talk about patterns, define and talk about components, and then there are other things, like grids and frameworks. We'll talk about all the similarities and differences of those.

In the second of the four chunks, we'll really take a look at how do you look at a design system and break it apart so that you can identify all the pieces and parts that you think you may need to standardize and then choose the ones that you are going to standardize. We call that discovery and organization.

And that's where we'll really get hands-on in each of these four chunks, but especially in that second one, we'll spend at least half our time cutting up pages and pointing at things and saying, "Yeah, that's a chunk, " and we'll all work together and say, "No, I think we should cut it up that way or this way."

Then the third of the four parts of the day is, really, actually creating a library and communicating it out to other groups. We'll talk about ways to embed your library into design tools, how to author guidelines and how to administer libraries, and end up with a hands-on exercise there, being the group's library they discovered in the second of four parts of the day, they'll communicate it to another team and have to teach another team what that library is.

The last part of the day is, we'll shift back into almost project mode, as you think about, "Well, if I'm heads-down on a project and I'm doing design, what it is that I need to do to leverage all these different pieces and standards to assemble a coherent design based on those?" We'll talk about variations of components, combining components into pages and patterns and so on, and even take a glimpse at what EightShapes does to document those designs, the very last exercise being we're going to ask that team that's learned from another team to build a page.

They'll get a secret assignment in an envelope and it'll say, "Build this page. Here are your requirements, and use that library those other folks gave you to do it." And we'll even include an extra nugget that some of the key parts of the page won't be available in the library they were taught, and they'll have to invent it on the fly, again, realizing that balance between inventiveness and define what the library is to extend it, as opposed to the deference you give to a library because it's already solved some of the problems that you face.

Jared: This sounds like it's going to be an awesome workshop, and I can't wait until it. Again, that's going to be at the User Interface Conference, November 8th through 10th. And anybody who's interested can find out more information at uiconf.com. That's uiconf.com.

Nathan, this has been awesome. As always, it's fabulous to talk to you, and I could just listen to you all day. I know you have things you need to get to. I want to thank you for taking the time, for sharing these thoughts with us today. This has been great.

Nathan: Thanks a lot, Jared.
Jared: OK. And I want to thank all of you listeners for, once again, spending time with us here on the SpoolCast. And as always, thank you very much for encouraging our behavior. Take care. See you next time.