The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #180 Nathan Curtis - Prototyping with HTML and CSS

August 30, 2012  ·  33 minutes

Listen Now

Download the MP3

Prototyping is an effective way to communicate design ideas. Static PDFs, PSDs, and wireframes can help get your point across but aren’t dynamic. Usually, any necessary changes are logged away as to-dos. They’re then taken back, fixed, and presented again. Nathan Curtis and the team at EightShapes are prototyping with HTML and CSS more in their design process. They find that employing these techniques leads to greater efficiency.

Show Notes

Prototyping is an effective way to communicate design ideas. Static PDFs, PSDs, and wireframes can help get your point across but aren’t dynamic. Usually, any necessary changes are logged away as to-dos. They’re then taken back, fixed, and presented again.

Nathan Curtis and the team at EightShapes are prototyping with HTML and CSS more in their design process. They find that employing these techniques leads to greater efficiency. Changes are updated as they’re being discussed, the team arrives at a consensus, and moves on.

With many teams transitioning to an Agile development process, prototyping in HTML fits in perfectly. Being able to have discussions and make those design decisions in real time strengthens team cohesion.

During this podcast, Nathan and Jared Spool discuss prototyping techniques in greater depth. You can also check out Nathan’s daylong workshop from User Interface 17, now in our All You Can Learn Library.

Full Transcript

Jared Spool: Hello everyone, and welcome to another episode of SpoolCast. I've got to tell you, we are going to have fun today. I have with me Mr. Nathan Curtis who is one of the principles at EightShapes.

If you don't know the folks at EightShapes, they are one of the top UX design firms, I guess, in the US. They are known for sort of leading edge thinking on how to do design and how to do design well.

We have Nathan speaking at the User Interface 17 conference talking about creating great prototypes that are effective for your team and for you to communicate. We're going to talk about those today. Nathan, how are you doing?
Nathan Curtis: I'm good, Jared, how are you?
Jared: I'm doing really, really well. So, you know, I've always thought of prototyping, as someone who came up through the development side, creating little code prototypes was something we always did.

When I got into doing UX design and working with teams, we're always into creating little sketches, little mock-ups. I always thought of it as just this way to get an idea out there.

But I'm realizing now that teams that do mock-ups and do sketches, and do prototypes and have that as part of their culture where they're always doing them, they work together differently than teams where it's sort of a special, occasional thing that somebody does as a side project and then they do it and forget about it because it gets dated pretty quickly.

Have you seen that in your shop? Because you guys, this move to prototyping has gotten more intense for you if I remember correctly. Right?
Nathan: Yeah, we've been on a path now for, oh goodness, over 18 months now where I've been trying to deliberately enhance the skill set of about two-thirds of the UX and visual designers at EightShapes to utilize HTML and CSS and prototype their ideas more.

Yeah, it has been a journey. Like you said, some of us have come from the development background where we're used to programming and working in code and opening up text editors and seeing what the design can become, and some of us aren't.

Like you mentioned, prototyping takes a lot of different forms. It doesn't have to be HTML, it could be by some software package. Like you said, it could be just getting together to sketch something out.

I think the nature of prototyping creates an environment that's distinct from our classical methods if you want to think of Photoshop PSDs or wireframes as PDFs in the sense that they actually bring people together to not just talk about the design and brainstorm about it verbally.

But it often leads to, during the conversation, figuring out the design and changing it together to sort of share the understanding of how it's evolving rather than talk about how it evolves and then have the spaces between your discussions be where one person goes off and tries to realize what you've talked about.

It's a habitual change for people to be able to pick up the pen or open up the code. Some people treat wire framing like that and just open up illustrator while you're facilitating a design review.

Even today after, what, 18 plus months I still have habits that make me resist those tendencies, and I have to get over them. I was meeting with one of my teammates, James, who is working on this responsive log-in page.

We were talking about, "Well, the desktop site looks like this. The mobile site looks like that." Only one of them had bold field labels and the others weren't. I said, "Well, why is it like that? Why don't you just adopt one or why don't you leave them like it is on the mobile site?"

He's like, "Oh, I can change it." I'm like, "No, no, let's just keep talking. Just log that one away." He's like, "No, seriously." Two seconds later he refreshes the screen and it's changed and we both agreed. That's the way the design went and we just moved on. It didn't become a to-do in Basecamp.

It didn't become some thing on his checklist of things to do. It just, sort of the conversation to resolve that tiny little sort of micro-problem already was behind us.

I think that's also what happens with sketching with paper too. You're talking about ideas. You just talk, talk, talk verbally about some of the visions you have. It changes when even one person, if not both, start to pick up the pen during the conversation because you might put a lot of those distinctions in your ideas or less good ideas behind you as you continue to drive the design.
Jared: I mean, that's really incredible to me, this idea that you're moving at such a rapid rate and you're able to knock some of these things off. I want to come back to that in a second.

But one of the things you said early on was that sketching is different than PSDs and interactive prototypes are different than wire frames and that they create this different work dynamic.

That's really interesting to me. Right? By changing the deliverable we get a different dynamic with our teams. What do you think that is, that it's causing that change to happen?
Nathan: Oh, there are way too many forces who come together in different ways to create that change. You could start with it's just the nature of how the design that we're creating is changing from sort of this page-based metaphor to things that are more responsive, more interactive within a single load of a particular page or what have you.

You could talk about the forces of development shops that are imposing change processes like Agile or what have you to force the design process to change in suit. I'd like to think that as we evolve our practices and as designers become more experienced and can learn faster from each other that we are creating better judgments around how to invest in certain design activities or not.

Lots of people are now having this sort of backlash against wireframes or static documents or what have you because they are realizing that so many of those decisions they can make to solve a design problem can happen a lot faster.

Some of them require PSDs. Some of them require that you wireframe things out and really deliberately think about some of the big sort of navigational decisions at play. Others like that bolded field label, oh my gosh, don't create a PowerPoint page or a bullet in your PDF to provoke that discussion. Just change the damn thing and move on.

I think that there are a lot of forces at play, but I think that the most interesting to me is how the habits that designers have are changing over time. It's been sort of a long-term change rather than just, "Oh, I see it's better this way. I'll always behave that way" because it doesn't work that way.
Jared: So what you're saying is some of this has to become almost second nature? The thing about the habit is that it's uncomfortable when you're not doing the habit and it's almost mindless when you are doing the habit. You're not giving it any of your attention. You're not giving it any of your direction. You're just doing it. It's really interesting.

I saw a TED talk the other day about this professor at Stanford who is creating these race cars that are self-driven. So it's like the Google car except it's going on a race track. To study how racecars are driven they studied how racecar drivers drive racecars.

They hitched some brainwave equipment up to a driver, and they can measure cognitive load by the brainwave activity. What they found was that when a driver gets into a skid there is no more cognitive load than just normal driving.

The racecar drivers have habitualized the movement. I'm wondering if that's similar to what we have to do as designers with picking up the pen and starting to draw. We have to make it such a habit that it actually has virtually no more cognitive load than when we're not doing it.
Nathan: Oh, there's no question about that. Even as I personally ebb and flow through intense projects or clients that need us to perform activities in different ways, I will sort of deform and reform those habits over time.

I think one of the interesting things about prototyping is the reality that if you're a designer and you want to prototype and you want to do it in HTML, it's not something that you do for a week and then you take a break for three months while you do other stuff and then you tackle it again in a week and break for a month and so on.

If it's not constant and you're not practicing it, the start-up cost that you have to reacquire a lot of even the basic knowledge to get started with a project or get in that mode of doing things is too much and you won't be effective.

Sketching is the same way. One of the things we do because EightShapes is largely a distributed culture, we connected with each other via Skype and do a lot of design reviews with our clients via GoTo Meeting or WebEx.

There's this interesting nuance with the camera that we use in that apparently whenever you launch it if another app on your desktop is loaded when you turn on this software, it says the camera is already in use by somebody else and you can't turn off GoTo Meeting at that point. You're already in the meeting.

So the habit becomes, well if I'm going to use sketching as a real time way to facilitate the design conversation, even if this conversation is about looking at some as-is software that we're just getting started with redesigning but I want to communicate through drawing, I have to start up my camera's viewing app before I start up GoTo.

And it's actually become a habit. My whole start-up routine is go to calendar invite. While my calendar is loading I load up my viewing app. Then I go to the GoTo meeting and launch that so I can share my screen and start sharing what my sketched ideas are remotely. Does that make sense?
Jared: Yeah, it makes perfect sense. These sort of automatic motions to me are really makes a professional a professional. Right? If you think of the progression that people go through, there's this idea of being unconsciously incompetent, right? I don't realize how bad I am at something.

Then suddenly we realize how bad we are and we move from unconsciously incompetent to conscious incompetence. Then we say, "OK, we want to get better at this" so we start to learn how to do it. We move from conscious incompetence to conscious competence.

But then that final step of moving from conscious competence back to unconscious competence, suddenly that's when I've picked up these habits, and I don't even realize that I'm doing them anymore. That progression, I think you're right, it only comes through things like practice.
Nathan: And repetition and continuity, I guess a consistent application of those behaviors over time. All of these psychological things are at the top of my mind right now because I'm reading this book called A Hundred Things Every Presenter Needs to Know About People by Susan Weinschenk.
Jared: Yes. Susan's got a couple of really good books out. That's one of them.
Nathan: But what I'm finding probably more interesting is the book is basically formed as a hundred different tips. Every tip she has I make this leap from actually thinking about myself as a presenter to instead thinking of myself as a designer because presenting is storytelling. It's facilitation.

It's being familiar with your audience. It's about sort of shepherding people towards a common goal. It's about teaching and learning. That's actually what our role as designers has become. She states that if you want to create some habits, and particularly as you want to think about the practice you have as a presenter, you need to really create something that is repeated over and over and over again.

She talks about some kinds of things that are more algorithmic take 50 times. Other things that are less algorithmic take longer or more repeated instances of them. But I think the same thing applies to both your individual behaviors as a designer on a project as well as sort of the posture you might take with the clients or formulating a process or rhythms with how you're conducting design with the other people you pair with.
Jared: This idea of practice, right, this is a theme that keeps coming up. Alex Rodriguez goes up to the batting cage every day, and he just hits balls for an hour. Tiger Woods goes out to the driving range and he hits balls for an hour every day. Right?

I've often wondered what is the sort of UX professional's equivalent of hitting balls for an hour every day? What is it we should be practicing to just keep our motor skills in play? Is there something around this sketching and prototyping thing that falls into that category?
Nathan: I think yes, instinctually the answer is going to be yes. But it's interesting you bring it up in that way because baseball players and batting practice, that's typically when the game's not on. Right?

So there's this notion of, "I can improve my capability as a designer by practicing these things essentially by myself." The crowd isn't there really. There isn't much of a crowd. Maybe there's a person pitching me things, but otherwise it's up to me to swing over and over and over again.
Jared: And, you know what? It's not about the outcome. Right? It's different than a scrimmage or going out and playing 18 holes. In those instances you're actually thinking about the score and the end result even if you're just practicing. But when you're hitting balls you're thinking about the act of doing, not the result of what you did.
Nathan: Yeah, and I draw a distinction between the effectiveness of that and how we make ourselves better designers in two ways. The first way is that it's solitary. If you start to take this mindset that, "I'm going to practice my sketching" or "I'm going to create this practice website by prototyping it on my free time or maybe EightShapes gives me a certain amount of time per week to try and just practice sketching outside of constraints, outside of partnering with other people, outside of feedback loops that are just some learning group working together every infrequent fourth week or something..."

What we found was that the solitary nature of that made it hard for people to remain motivated and get feedback when it actually wasn't in the context of something real. So just like people complaining about's website, which I have a lot of complaints about, they are dealing with a lot of constraints that I don't understand.

It's foolish for me to think that I can, without constraints, design something that's perfect and just imagine that's going to be so. The other thing that is different other than it being solitary and without constraints is the fact that it's not during your real time.

It's not when you're actually practicing as a designer, in our case as an agency, in a paid fashion to create value for one of our clients. What we've found is, we've tried to create learning groups.

Those are helpful. It brought us together. We talked a lot about our practice and our technique. The only people that grew, and the people that grew faster, were the people that did it on the real projects.

So the feedback I give inspiring prototypers is you can't just limit yourself to doing it on weekends or doing it in an hour long chunk on a Friday afternoon when one foot is out the door waiting to go see The Dark Knight Rises.

Instead find projects, take risks, be ready to fail, but you'll be able to fail with feedback so you can continue to drive and practice that consistently with that continuity I'm talking about. That's where the growth has come. The people that have gone the furthest at EightShapes have done that.
Jared: That's interesting. Right? I've often thought that there was something to this sort of solo practicing thing. The idea that you need to, at a minimum, also be doing it along with the team in the context of the real project if not that's how you always do it, that's really interesting to me.

Because I think that we don't get a chance to sort of look at and deconstruct what we're actually doing. We're just always pushing forward, always pushing forward and never get a chance to look at those actions, those activities and think about, "OK, that was interesting, but was there a better way to do it? Was there something that was more interesting?"

To go back to your point about habits, the idea is to do it frequently enough that it becomes habitual. Right? So there's a tension there. Because sometimes in projects you only do things once and you never do it again because it doesn't come up.
Nathan: Exactly. So one of the things that we've realized too, particularly with protyping, it's the restart that ends up being frustrating. As a runner and as a late 30s runner now, I'm realizing that I can't go out every time and run really fast.

In fact, I run infrequently enough that, even though I might run once or twice a week, there's enough space in between each of those runs that, like I told my wife, I keep hitting against this threshold, this ceiling of the beginner's level of fitness.

It's only if you start running, and it's the same thing with protyping or any kind of habit you're trying to develop, if you run often can have a day break and actually sometimes have a day long break where you don't run is a good thing. It lets you sort of ease and clear your mind.

But once it stretches to two or three it's that second, third, and fourth day that you really just drop everything and your level of fitness goes right back down to the basic level it started from. Yeah, I can really identify with that.
Jared: What's the sort of balance do you think? How do you find a way to keep up those skills? I think sketching is definitely probably a little easier because you can sort of sketch ideas as you're talking in meetings.

But the HTML prototyping thing, that's one thing where there are just phases of a project where you're not ready to get to that level of fidelity. Right?
Nathan: Yes, and in fact it's an obvious comparison in that the order and magnitude of the investment you make is commensurate with the fidelity of the thing you're making. You're sketching, it takes a minute or six minutes.

If you prototype a basic page layout, maybe it takes 60 minutes to throw a bunch of divs and then orient them on the page. To actually add behaviors, maybe it takes 300 minutes. Then to actually start to make things move around in a rich way and have some data moving across screens, you're talking about an order and magnitude even more.

Actually I would say there is a correlation of that increase in investment and increase in fidelity in terms of the increased costs that you'll have by not doing those things habitually.

Some of us don't need to go that far down the path of making rich prototypes that have a lot of data moving in and out of all these different pages. That isn't necessary for the designs that we need to articulate.

Another thing about how projects break down is actually this move that we're making from this classical sequence of activities that we've had in the past. You do discovery. You do wireframes. You do comps. You maybe do prototypes parallel to comps because it's stable enough of a design.

Maybe you assess that prototype in a research session, and then you deliver it all in one big spec. That's the waterfall. That's the easy to understand sequence. In terms of a first way to learn this progression of fidelity of the design is easy to hang your hat on. But the problem with that is, like we see in the jumbled up mess that all these activities are being thrown into because of things like Agile and actually are sketching all the time and prototyping all the time.

Maybe you're using a drawing tool to create a wireframe that you throw away 30 minutes later. So this nice, rigid sequence of basic steps is sort of really disrupted. It's hard to persist this habit forming based on a technique with HTML and CSS if you don't know necessarily when you're going to apply that skill in any sort of rigid, repeatable way.

What I found in this project we did that started seven months ago and is just coming to an end, we actually prototyped a lot early on to get people to have a common language, to start to frame out how the design could be realized.

There were aspects of the project that the teams just weren't responding to prototypes. Admittedly, we reverted to wireframes. Our deliver over that middle to later part of the project, the tone changed.

The way we were collaborating changed. The way that we went back and forth with how we utilized wireframes in the process ended up creating far more common understanding, but it was because of all these other conditions of the project that I won't get into.

It really convinced me that, no, I can't use protyping every single time to solve every single problem because you've got to bring your own set of tools to different projects and different design challenges based on the conditions that you're presented with. Yeah, that does create a challenge for that habit forming practice that we're talking about.
Jared: One of the things that I think doesn't get played up enough is this idea of really quickly crossing things off the list without them going through the to-do list item. Right? This idea of, "Hey what if we did this?" "That looks much better, OK, let's go that route."

How that change and that sort of collaboration, it's not just the act of putting it on the to-do list, assigning it to someone, having someone do the work and then checking it off the to-do list. That in itself is what I'd call tool time, the type of time that doesn't add any value to the end result. It just takes up space.

There is also probably some type of flow, I would think, that you would get to that is really meaningful and helps get to that sort of shared understanding about what you guys are building much faster. Does that make sense?
Nathan: It does, and I think both of those things, the flow and the reduction and what you're calling tool time, I call sort of the meta cost of just collaborating and organizing a project or managing a project.

That tool time costs and what you're talking about with flow I think is helped by the fact that more often we're finding ourselves collaborating in smaller groups or even a pair of people.

To make these behaviors happen so consistently when you're collaborating face to face or remotely or you're paired prototyping with somebody else and you're really trying to solve a problem between two people. The back and forth between two people is a lot less expensive and a lot more frequent and sort of decisive than it is to have a single person work in isolation, say for a week.

Then on Friday afternoon have the design review that actually then you're going to want to have six, seven, eight project team participants all reacting to the design at the same time, and the same level, injecting a lot of diverging opinions.

There's a case to be made for those kinds of reviews, but if you have two people working and collaborating, say a design and developer, up to that point then a lot of those problems that everybody is sitting around the table and just gabbing about I think have already been solved.

That bold form field label, for example, is one where it could erupt into a stupid 10-minute conversation around who last updated some guideline on some Wiki somewhere or which person's design system, the guy that owns the desktop system or the woman that owns the mobile system, is going to win out from a sort of governance perspective.

Instead you just made the decision. You moved on and nobody even noticed because it's good enough. Does that make sense?
Jared: It does, it does. It also occurs to me that there's a message on the sub carrier there, right? You know, it's not just about changing the bold field. It's about, "Gee, you know, if we made that field bold it will stand out more. And because it's such an important field and the reason it's an important field is because it's one of the things that users are coming to the site to do."

All that understanding starts to play in and now everybody at the table is hearing not just the change and the rationale for the change. So often in a to-do list item the rationale is filtered out.
Nathan: Absolutely. I think that while people talk about Agile and sort of these more collaborative approaches as ones that reduce the contract that is created through paper or documentation, in fact, really that contract is being changed or transitioned to hundreds of micro contracts that you're already making verbally and you don't need to aggregate into some doc.

Yeah, it's going to be something that you agree on. Those rationales, maybe the fact that fields are left aligned, that you have a label on the left and the field on the right, that you make the field label bold or just normal weighted, those are three sort of micro agreements that you just make and move on as opposed to sort of opening up for the mass of people to talk about through documentation.
Jared: That is so cool. I think this whole idea of getting the team smarter about why you're designing through the sketches and the prototypes that you create is really quite powerful.

I heard a rumor that you guys at EightShapes have created this magical new technology that instantly transports remote teams to all be in the same physical plane at the moment to look at your sketches. Is that true?
Nathan: That's a slightly bent version of the truth, but yes.
Jared: [laughs]
Nathan: Yeah, we've had to figure out ways to get people to sketch together when they're not in the same room. It just amounts to a $70 camera that all of the different locations have.

Honestly, we use in a single location sometimes, because the room's big enough and standing around in a circle of 15 people even makes your tiny little sketch on an index card a little hard to see from 15 feet away.

So if you're referring to our IPEVO camera and the way that we utilize it to bring people together, yes, that's true.
Jared: Yeah, it's exactly what I was talking about. Say a little bit more about this. I'm particularly interested in this idea of setting it up and using it in the meeting. And I'm assuming this is one of those habits that you acquire so you just sort of start doing this without knowing whether you're going to use it or not. Is that true?
Nathan: Yes. The first thing is the problem -- what triggered it. And what triggered it was when we were trying to sketch with people that weren't in the same room, you'd get one of two solutions.

Either people would hold it up to a camera being broadcast in reverse on a WebEx that's on somebody's monitor, like on somebody's display, like a laptop embedded iSight camera.

Or everybody, after a round of six minutes sketching based on some task, pulls out their iPhone, takes a photo and then sends it somebody's email inbox. You then have to wait for them all to arrive, and then you start presenting sketches from an email attachment, which is ridiculous.

I found a camera. It's called the IPEVO point of view camera, and it actually is similar to an ELMO but a lot less expensive, and it just captures downward from its stand the image of you sketching on a table top. It then broadcasts that through an app that you can share via GoToMeeting or WebEx or what have you.

That helped us bring together our remote people -- not just from DC, but we have a couple people outside DC.

But then, what we found, too, was that we started doing sketching studios frequently with our clients at sometimes a remote. Get them a camera and then we figure out a rhythm for three people in one location to share, and then three people in another location to share.

It's gotten to the point where now all of just have a camera on our desk. If you were to look at my desk, I have my main display in front of me. I have a secondary display to my left, and to my right is this sort of foot and a half by foot grid on top of which this IPEVO camera is perched. And next to it stacks of blank paper in index card form -- 3 x 5, 4 x 6, 5 x 7 -- suitable for different handset and tablet sizes, by the way.

I just pull those out and I have the camera ready at any point, and we just start sketching all the time. It's got a dedicated space that is within my arm's reach from where my keyboard is. Yeah, it's embedded as part of the way we interact with each other.
Jared: That's really neat. I mean, you've got this fairly inexpensive piece of hardware. It's less than the new power supply I just bought for my machine.
Nathan: Yeah, really.
Jared: And it is right there. You have it right next to you, so you can pretty much use it. You've got habits in place, so that you can just grab them and have it set up so -- maybe you don't use it in most meetings, but in the meetings when you need it, it's there.

All of a sudden those costs of setting up and getting ready and "Hold on. Let me call you back in five minutes, and we can sketch this thing." And, of course, the minute you start setting up equipment instead of sketching you forget about all the brilliant ideas you had that you wanted to sketch.

It seems to me like that's the type of habit we were talking about, right?
Nathan: It is. And it's easy to dismiss. They're like, "Oh, yeah. I get it. You have a camera. All sorts of things have cameras now. I get it. You're sketching and you need to connect people that are distributed."

And then I reply, "Yeah, but a few months ago I sketched out three screens on 5 x 7 cards, and ended up selling a project that lasted four months, that included our first and maybe only client side UI dev, that had lots of JavaScript from design strategy, information architecture -- all the different services we provide, usability research.

We did all these things, and it was all triggered by three sketches I shared with a client who wasn't in the room. It took me five minutes, and I sold it all by just some Sharpie and pieces of paper.

So that, to me, is powerful. That to me signals that, yes, we need to change the way that we conduct design and facilitate conversations because it worked. Hopefully it's had good outcomes since then.
Jared: And none of that was planned, right? You didn't walk into that meeting saying, "I'm going to make three index card sketches and sell $75 billion worth of project."
Nathan: Yeah, it was only in the millions or slightly less than that, but no, actually the intent there was that we did some paired sketching with James again and myself. That sketching was our... let me back up.

We had a design studio with a client. This theme emerged, and nobody really realized it during the design studio, but then when James and I reconvened as designers after that to consolidate ideas and recommend a direction, another light bulb went of. I sketched it. It took about 10 minutes to conscientiously sketch this. It was a little bit more polished than usual.

We said, "Let's get the client on the phone." Five minutes it took me to present it and boom, the whole project changed and it sort of exploded from there.

So yeah, it was a little deliberate in that we started the meeting knowing that we were going to share sketches, but it also wasn't some big keynote project proposal with all sorts of figures. It was essentially two guys talking to each other about sketches and trying to figure out how to launch a product that's six months later or three months later.
Jared: That's so cool. And about the billions thing, I'm sorry about that. My staff has told me 100 million times not to exaggerate.
Nathan: It happens, but it wasn't that far off.
Jared: Hey, dude. This has been really a lot of fun. I'm really excited. Thanks for talking with us about this today.
Nathan: It was a pleasure. Thanks for having me.
Jared: Everybody at home, I want you to know that Nathan, if he thought this was really interesting you're going to love his full day workshop. It's called "Prototyping to Achieve Super Strength Team Cohesion." It's going to be on Wednesday, November 7th in Boston at the UI17 conference.

Of course, you can find out all about that at We would love to have you there. Nathan is really amazing and is worth the $700 billion that we pay him for this.

I want to thank you all once again for listening and, of course, thank you for encouraging our behavior. We'll talk to you soon. Take care.