Nathan Curtis – Start Full Screen: Organize, Communicate, and Annotate HTML Prototypes
Podcast: Play in new window | Download (Duration: 32:09 — 0.0KB)
Subscribe: iTunes | Android | RSS
Nathan Curtis and the team at EightShapes are experts at creating modular components and libraries for developing PDF documents. But as they transitioned away from static PDFs to HTML prototypes this approach had to adapt as well.
In his virtual seminar, Start Full Screen: Organize, Communicate and Annotate HTML Prototypes, Nathan discusses how the team at EightShapes brought this philosophy to creating rich interactive prototypes using HTML, CSS, and JavaScript. He explains how, through modular thinking, they were able to write scripts that chunked aspects of their designs to repurpose and reuse across multiple pages.
Nathan and Adam Churchill address some unanswered questions from the live virtual seminar in this podcast:
- Should you start with sketches and then move to HTML?
- Do the modular techniques work for complex web applications?
- What’s it like to work with a visual designer with this type of workflow or process?
- How does viewing grids of pages work on smaller devices?
- Are you using media queries for creating responsive designs?
- How are you providing long user journeys without having to build entirely in JavaScript?
- Why wouldn’t you just use something better and more advanced for prototyping like Axure or Fireworks if you’re not producing production-ready code?
- Does using components and libraries lower creativity?
As always, we love to hear what you’re thinking. Share your thoughts in our comments section.
Recorded: May, 2012
[ Subscribe to our podcast via 
←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Full Transcript.
Adam Churchill: Hello, everyone. Welcome to another edition of the SpoolCast.
Recently, Nathan Curtis joined us for a special online seminar, “Start Fullscreen — Organize, Communicate, and Annotate HTML Prototypes.” In it, Nathan shared how his team at EightShapes brings its philosophy of modular components and libraries for producing .pdfs to prototyping using simple HTML, CSS, and JavaScript.
This particular seminar has been added to our User Experience Training Library which presently has 92 recorded seminars from wonderful topic experts just like Nathan giving you the tips and techniques you need to create great design. Hey, Nathan. Welcome back.
Nathan Curtis: Good to be here, Adam.
Adam: For those listening who weren’t with us for your awesome seminar, can you give us a bit of an overview?
Nathan: Sure. We talked in Start Fullscreen about EightShapes’ approach to prototyping and how we’ve built a library to support the various aspects of our user experience design process in the form of HTML. Really, it’s divided into four parts and we spent the first 15 minutes or so just talking about the rationale and how many of us had taken up HTML prototyping. We use a lot of the existing kits that are out there like jQuery and 960 Grid and Foundation from Zurb and lots of other things.
But really, it wasn’t meeting the needs of what we do from a client services perspective in delivering our product and communicating it well to our clients. The subsequent three parts of the seminar covered first modular thinking and how we wrote scripts so that we could divide or chunk out our design into pieces like the header and the footer, navigation, and repurposing all of them in modular ways so that we can reuse them across many different pages and also really control our code base a little bit better and collaborate better with it.
The second of the three parts was how we organize our experience and really take advantage of CSS3 to rescale entire pages down so that we can load multiple pages into the browser at once, show flows or galleries of pages, position them side by side to make decisions around design alternatives, which when you’re working in a browser typically you’re just hitting forward and back in the browser and it doesn’t work as well to actually see and compare things side by side.
And then the last part of the seminar, we talked a lot about how we annotate designs. Really, when we reduce the size of the page in a browser window so you can see it at a smaller, maybe even at times thumbnail size, how do you label it? How do you describe it with different notes? How do you do a lot of the common things that you do when you’re using .pdfs and wireframes, but in the context of doing HTML instead?
We’ve had varying degrees of success with that. Sometimes we never even need to do that. But creating a framework enabled our team to do this consistently for the clients across the 12 designers that we employ in varying ways for them over time.
So it’s a good exploration with that and then we really concluded with a little preview of some things that we do to responsively design in that context, too.
Adam: Let’s get to some of the questions that we had from the audience. One was that folks were wondering if you start naturally from sketches then into HTML, does your team at EightShapes avoid the boxes and arrows stage all together or is there a similar element that you folks are using in the early stages?
Nathan: There are projects, admittedly, where we don’t do any site maps and we don’t do any sort of wireframes at all. We just go straight into code. Maybe we sketch first with some Sharpies, but it’s because we have libraries built for specific clients that have all of their components already established.
A client that we have is Cisco, and they have a big modular library of stuff. We know what their header is. We know what their heroes, so to speak…Billboards at the top look like and how they function. We know how they put tiles all over their pages and use RightRails and so on.
In those cases, yeah. We go straight to HTML and it becomes more of a strategic content exercise rather than a UI design or page layout exercise because those modular bits are already established.
But on most of our projects we ignore boxes and arrows and some of that design planning at our own peril. When we’re working on complex web applications, you really still have to think through those bigger implications and think about that forest of the entire design system, how people are going to traverse across pages, how they’re going to really go in and out of different interactions on specific pages before you start building everything.
If you go straight into HTML you really run the risk of building and then rebuilding and then rebuilding as you iterate without really having a clear sense of where you’re going. And so, be it site maps, be it really conscientious sketching, there’s lots of things that we do that precede going into HTML in many cases.
Adam: I think this question relates to some of the examples that you showed earlier on in the seminar. The comment is, “This design is a pretty simple content layout.” The question is, “Do the modular techniques work for complex web applications?”
Nathan: Yeah, for the purposes of the seminar we focused on a really simple trio of layouts that are standard desktop web pages. They had a header. They had a footer. One of the pages had a big grid of paintings. And another layout was actually a page describing a specific painting that had that painting really large and it had descriptive information next to it.
And yeah, I think it’s a legitimate sort of instinctive criticism to say, “Oh, these are really simple designs. Your framework works on really simple stuff, but what about sophisticated web apps?” We actually do a lot of that design, but those prototypes take a little bit more time to build, admittedly. And I didn’t have any prepared to share because some of the basic concepts are harder to grok with those more complex apps.
We do things like…During our design process we were working on a blog site. We asked questions like what if this thing was like Twitter for iPad? You had all these panels sliding in and out. What would that feel like? How can we make each of those panels perhaps repeatable in a modular component so that we extract those and one person’s working on those and another person’s working on the header and the sidebar.
And we also had really detailed patient record applications that we work on, too, where you have a lot of different components, a lot of different UI limits. And actually, it’s to our advantage to modularize those so as we collaborate across, say, two or three or four user experience designers you really have to divide and conquer the work.
The bottom line is you have to prototype in these situations and you have to actually figure out a way to segment the work so that you can all share common assets but also drive towards your individual responsibilities. And working in a flat environment, I would argue makes that harder that it does when you’re working in HTML with some of the opportunities you have there.
Adam: What’s it like to work with a visual designer with this type of workflow or process? If you work side by side with developers in a lean approach, would you suggest building prototypes that could produce production ready code or stick with this Blocks framework?
Nathan: That’s really two questions in one. Let me tackle the first one around working with a visual designer. We’ve had a lot of success getting rid of our typical process of two to three weeks you iterate and refine and stabilize your wireframes and then the visual designers starts to get involved and sets a visual direction. And then, once those wireframes have been done, you just do the concept of each of those page types.
I’ve tried to disrupt the process here at EightShapes to varying degrees of success, but it’s been really rewarding most of the time. We actually sat down next to each other and from the ground up, for four or five days straight, we built a web site. We did all the visual design and we made all of those decisions together by really forcing each other to ask questions in real time.
I would point at the screen and say, “What are you doing with this button here? Is it really going to overlap with this other area of what you’re trying to visually design in that way? Does that work right?”
And at the same time, there’s a visual designer, Jody, I work with and she’ll point to the responsive prototype I’m building and say, “What’s with that percentage based gutter you have in between those two columns? Is there any way we can make that fixed so that it doesn’t become really large when the page width gets really large.”
We really push each other and I think that face to face direct collaboration really benefits the time that it takes us to do it. It does come with a little cost, however. It does disrupt our typical ways of doing things. I remember she remarked, “I’ve got this whole comp that I can create to depict an entire page and solve all the problems together, but when I’m designing…When you’re prototyping next to me, I end up not having any representation of the page design at all and I’m just working on all these little micro component or elements…Things to get you the CSS kind of definitions you need to prototype it in code because the prototype ends up becoming what we share with the client, not .psd files.”
And so there’s a little tug there. There’s a little exiting your comfort zone and trying to share the definition of what the design is. That comes with a little bit of a cost.
The second question you asked, I think, regards more the use of production ready code. When you said, “When you’re working side by side with developers on a lean approach, would I suggest building prototypes that use production ready code?”
Absolutely. If you have a starting point of production ready code and you have designers that are capable to sustain that quality of code and quickly realize the design, then definitely stick with production code. I would characterize though that, at least at EightShapes, we don’t find that those conditions apply in two ways.
The first way is we don’t often find ourselves sitting side by side with developers based on the way that our consulting services work. We’re more typically trying to finalize the design and overlap our design process with development. But it’s rare, if ever, that we would get a client to actually sit with us, side by side.
But the other thing, I think, is that for most of us at EightShapes as user experience designers, myself included, we don’t have neither the confidence nor the capability to quickly execute production level code while still meeting the time constraints we have to solve the design problem
If that means that as designers we take shortcuts. We don’t label our form elements. I’ll be honest, I don’t even put a form tag but we use an input tag for a text box.
Heck, yeah, we’ll do it because your responsibility isn’t doing that production level code. It’s solving the design problem. I’m fairly adamant about that, because I’d rather see designers prototyping to realize a better design solution before I see designers get hamstrung and frustrated and take a lot longer because they’re trying to solve production problems during a period of the project that doesn’t warrant it.
Adam: A couple of questions involving designing for devices. How does viewing grids of pages work on smaller devices?
Nathan: It doesn’t really work. The thing we presented during the seminar, this EightShapes Blocks JavaScript toolkit that we built, makes the assumption that when you want to talk about multiple pages at one time, we’re going to take that screen design that’s within a section tag, as it were, within your HTML markup and we’re going to scale it down.
That means that we’re going to show, at times, four or five pages across the single browser window, all of which are actually full page displays. But when you think about the way media queries work, they depend on the width of the browser window, not on the width of the actual element that contains the page layout so it sort of breaks that model.
That said, we do take some approaches that fairly similarly map to the responsive web design principles of using media queries. One thing that you can do is you can take JavaScript and just attach a class for the body tag that effectively mimics the logic that the media queries have and the CS rules they’re used in.
The other thing is sometimes we never exit full screen. If we know we’re not going to document the design, if we know that the design is fairly simple or limited, say a five to seven page type site design that we need to just crank through. We can just crank through and really navigate the prototype sufficiently to show the different page designs. Then it never makes sense to leave full screen and reduce those page sizes. In that case, we’ll just use media queries right from the outset.
But in either case, I think the key thing is thinking about the conditions by which your design changes based on the browser window and whether or not in the design process you actually use responsive or designed media queries, or you use some sort of JavaScript technique. As long as you’re solving the design problem in a way that it can really be built out appropriately, I’m less concerned about the purity of your coding choices that you make to accomplish it.
Adam: Nathan, you mentioned media queries. Are you using them for the responsive designs that you folks created?
Nathan: Yeah, most of the time we do, honestly. That’s where we start. For example, a project I started about three weeks ago, we started…This is when I’m sitting side by side with the visual designer and I made a choice from the onset to use Zurb’s Foundation. If you go to Zurb.com and you can find their Foundation toolkit it’s this set of row and column based grids that you can use to design responsively.
I immediately understood how the kit worked. I started to design and started to actually extend the break points that they had for, say, handsets versus larger tablets, to create more micro break points so how the designed changed at different widths.
It all went really fast and honestly, I used the EightShapes Blocks framework for all of the modular parts, meaning I still took a header and put it into a separate file. I still took a footer and put it in a separate file. I still took a big image of a product that was on the site and created variations of that.
But I didn’t use the exit full screen stuff, and so I just stuck with media queries from the outset, and it worked great.
There’s another project that I’m on that is a little bit longer. It involves, I would argue, 50 to 75 unique page types, many of which have variations and forms and all these other considerations where I created my own way to mimic the responsiveness in JavaScript without having to use media queries because it was really important for me to be able to exit full screen and tell deeper stories about each of the pages.
So really it just depends on the project.
Adam: As web and mobile applications are becoming more of a focus for user experience designers, how are you providing long user journeys without having to pretty much build the whole thing in JavaScript?
Nathan: That’s a great question. In some cases, the prototype you build in HTML is simply an alternative to the static paper based or .pdf based design that you might create in InDesign, or OmniGraffle, or what have you because those products, through .pdfs, enable you to hotspot different places and traverse from page to page.
But really, that doesn’t take a lot of JavaScript knowledge. That just uses simple anchor links.
When we really start to work through the design and you start to think about the more nuanced interactions, you want to be able to express those. And so, jQuery and other tools enable you to out of the box do a lot of basic things. And then it’s up to the designer to discern whether or not they’re comfortable and that they have the taste for learning more detailed programming to really detail that interactive story.
There’s a few people at EightShapes that have continued to drill into that more and more. We’ve seen really positive outcomes around their ability to express their design solution. But yeah, it starts to drift into programming.
There is the other end of the spectrum, I would argue, that I’ve found myself going down into that hole of that health records app that I’ve been working on where I start building all these data structures in the code. I’m starting to manage all these different types of records that the patient has. There’s a medication that’s ordered or there’s a lab result that needs to be requested.
You start to move a lot of data around in the background and the reality is, “Oh my gosh, I’m building this entire application’s front end and it’s taking me a long time.” My ability to shift the design, because if I’m not getting the design right becomes a lot harder because I’ve build the whole thing.
And so, actually, we backed up. We stopped doing a lot of our scripted prototyping in that case, took a pause, and did a lot of wireframing. And then we rocketed forward again and we had a much more stable base to then rebuild a lot of those interactions in. Actually still mimic a lot of that detailed stuff in JavaScript later on, but it had a good foundation to build upon as opposed to building that kind of script week to week for every successive client review.
Adam: A couple of our audience members were looking for some reconciliation on some things that you were talking about. On the one hand, you tout reuse and efficiency. But on one point in the seminar you explicitly denounce making your code reusable for production.
I know we just talked about that a few minutes ago, but for this particular attendee, can you reconcile those two?
Nathan: Yeah, it really depends on conditions that you’re finding yourself engaging into the process because let’s take EightShapes. We’re a design consultant. We get hired by our clients to do design engagements and deliver the design. We don’t do development. We don’t implement sites. We’ve done it maybe two or three times in our six year history and we don’t do anything like database or application development.
And so, our focus is just getting the design right for the most effective cost and in the fastest time that we can for our clients. And so when you layer some of those assumptions on it, you’re darn right. I don’t care about production level code. I’m caring about solving the design problem because someone else is going to be building the templates or building the application layer and it’s really their responsibility to do that stuff.
It’s not like I’m trying to pass the buck, because I think in certain times what I would prototype would help educate them and really feed their appreciation for the nuance of how they should build it. But even in house at EightShapes, I fancy myself a moderately good HTML and CSS guy.
We have another guy, France, who is a total whiz at HTML and CSS and he does a lot of our production level template creation. He always looks at my stuff and he sees all the shortcuts I make whereas the client’s very happy with the solution of the design problem, he’ll throw it all away anyway, even though we work together because he knows that there’s a better way to adapt that markup to work on Internet Explorer 8, to work on a Blackberry, to work on all these different types of browsers that degrade in various ways.
Whereas I’m trying to keep those things in mind, how those things will degrade but I can’t, in my design process, express all those things. That’s the kind of denouncing making code reusable for production that I’m talking about, whereas the reuse and efficiency we’re talking about is just making the design process and the collaborative process across designers in the same project work smoother and work faster. That’s admitting all my own biases and where that viewpoint comes from.
Adam: One of our attendees was looking for you clarify the payoff. If not production code, why wouldn’t you just use something better and more advanced for prototyping like Axure or Fireworks?
Nathan: That also comes laden with biases. First of all, someone’s ability to code fast, because one person’s, “Ah, I’ve done some HTML in the past. I sort of understand what all the tags are,” is a lot different from the UX unicorn that people describe that can really do all of their design in code super fast and is super talented at even JavaScript. Their bias, in terms of their skill set and their experience, will definitely influence the decision they make around which tool works for them.
I don’t really feel like you can win a “My tool is best,” argument. Even at EightShapes, we try to be cognizant of the skill sets and really the postures that people bring to the design process just as much as what the needs of a particular project are to actually select the best tool.
There’s a person at EightShapes that we encourage to prototype in Keynote all the time. They’re really a whiz at that. They can do some things that I don’t even know how they’re doing them in Keynote. But that person doesn’t have the skill set that I have to do HTML based prototyping for a electronic medical record. And so, we would bring different skill sets and choose different tools to accomplish the design goals that we have.
The other things is this prototyping in minutes is a bit misleading. I think that another comment that I saw from the seminar was that, “I can create a prototype in Axure in minutes and it’s super awesome. Nobody can do that in HTML.”
Which, again, it comes back to that level of experience. At EightShapes, we have this event every month where we all get together. We call it Share and Care. It’s a really goofy name, but we actually bring a lot of our work and present it to each other to get design feedback, as well as we do more focused presentations on topics. And also sometimes we’ll actually do these creative brainstorms.
And so, one of our design leads at EightShapes recently got his hand on a book and I’ll look it up, but I don’t remember exactly what it is. It’s by a gentleman from Frog. I think it’s like Creative Workshops that came out earlier this year. Yeah, it’s called The Creative Workshop.
He ran it and it was a half hour exercise where everybody sketched out stuff and the solution was, “Take this brochure, sketch it out as a website constrained to this grid that you roll a die and that’s what your number of columns in your grid is.” Then take that and design it for a handset web based design with the same grid assumptions.
It’s a great creative quick-fire kind of thing where we each had 30 minutes. I sort of ignored the instructions and I said, “I’m just going to build this responsive website and code and see if I can do it in 20 minutes.” And I did. I met all of the constraints of what the exercise was. I did it all in HTML. I used Zurb’s Foundation because it was top of mind terms of how it all worked. And I produced an HTML prototype that actually flexed to all the screen sizes.
And so when you say, “I can build prototypes in minutes using Axure but it will take me days in HTML,” that’s a little bit biased, too. It really just depends on how strong you might be in one or the other tools to really render the inspiration for the design that you have.
Adam: You talk about annotations, and a comment that some of the examples that you were showing, they seemed fairly sparse. So a concern is do the developers of these designs end up asking a lot of questions?
Nathan: Absolutely. Isn’t that wonderful when they ask questions and it’s not like this big wall you throw this stuff over? Actually, that’s kind of the point with a lot of these more contemporary processes like Agile, is to create the conversation so you don’t need to document everything. The documentation is this sort of contract that you have by the nature of the communication you have between the members that should be fluid and constant and deep to develop that shared understanding. We have projects that are like that.
There was an example in the seminar that I showed called “Saving the Dream.” It was a small website. We did a responsive design and we used HTML prototyping and it was great. But actually we did a lot of this work in such close collaboration with all the different participants in that design and development process that we didn’t use any annotations at all.
It was kind of ironic because I was building this whole tool that enabled you to exit full screen and put all these annotations next to all of your designs and compare them and so on. And I didn’t annotate anything. And you know what? Sometimes you don’t have to.
That’s really, really a great thing but there are other conditions, like this electronic health and medical record project I’m talking about. 35 developers all spread across five different tracks of work. It’s just this massive scale. I’m just trying to communicate patterns like, “When you’re going to a subpage, you’re going to have this navigation on the upper right where you can traverse the subpages without going back to the hub of the main page.”
That’s something that I need to communicate to everybody. That is something that needs a little bit of documentation. That actually would be a pattern that we’d be trying to build into the design system. In that case, it’s entirely appropriate to develop that documentation to answer those questions on my behalf because I can’t talk to 35 people at once.
Adam: This section on reuse and components in the seminar, it talked about how to include different components. You didn’t apply…You have a library of components you use most often in this system like a calendar picker, for example. Are you building a library for those, too?
Nathan: Not really. In fact, like I mentioned at the beginning of the podcast, we do have some client specific libraries that help us render designs fast because all of the components in the visual design system, all of that’s already established for us. We don’t need to build that every time.
But on our projects where it’s kind of a blank slate, we’ve got a big white canvas, that’s really your place to create the new design system from the ground up. We might use some tools like Twitter Bootstrap or other types of libraries that help give us a little bit of a head start on those things, but we almost always develop most of the components from the ground up ourselves.
That was really the spirit of the framework that I was trying to create with EightShapes Blocks because I actually tried to control almost nothing about what goes in that white box where you actually see the screen design. When you’re in full screen view, it’s the full browser window. The only thing we put on top of the design were just boxes that identified where the components were.
If you look closely, nothing else is controlled inside that white box. Instead, we really tried to focus on how to communicate around the design and communicate things about the design outside that box.
Adam: Nathan, you showed a lot of screenshots with the audience and in the header of each there was a component section that had not been shown. Can you tell us about that?
Nathan: Sure. This is actually referencing when you leave the full screen and you essentially reduce the size of your page design so that you can show it next to other pages or you show it with notes next to it.
There is this header navigation for what, in essence, is your deliverable of the prototype. It has, in the upper left, it tell you, “This is the prototype for the 8Shapes Gallery of Painters.” And on the upper right there’s a navigation to get to a home page that we built, the gallery of pages that are a part of the design. And then next to that is a gallery of components.
We’ve actually built out a way to take the components out of the context of each page but still present them in a meaningful kind of grid automatically. And so that you can traverse things like, “Oh, that’s what the header looks like,” or, “Oh, that’s what the navigation on the right looks like.” Here are four different variations of that navigation that I can look at next to one another.
It’s kind of a bigger challenge, though, because when you take the components out of the context of the page, they really lose a lot of the context of what kind of container, how wide should they really be when we take them out of their context of, say, a column of the design. And also, sometimes they inherit some of their style properties from tags within the page layout that aren’t actually part of the component code but might exist a little bit higher in the document object model that they’re contained within.
So we’re still working on it. We didn’t share it during the seminar because it’s a little bit crude, but still actually effective when you add a few more layers of detail. But I wouldn’t say it’s smoothed out for the masses, so to speak.
Adam: Nathan, at EightShapes when you are reusing these modules and code across different projects, are you running the risk of lowering creativity?
Nathan: That’s actually kind of a softball question around patterns in general and reuse in general because sure, in some projects like the client specific libraries where the visual system’s already defined and you have headers and footers and other things you can reuse. Absolutely you want to reuse those over and over again. That’s why you built the libraries in the first place, to create consistency, to increase efficiency, to reduce maintenance costs.
But there are many in the user experience discipline that disagree with the concept of patterns because they feel that it really reduces the creativity and the license a designer has to solve design problems.
I think design happens all the time within a set of constraints that many of which you can’t control and many of which you should actually embrace as a way to help you narrow the scope of the design problem you actually need to solve.
That means that if you’re working within a website design where the header and footer is already defined for you, the object of you working on a specific page within that overall design system is just the body of the page. You should reuse the header and footer.
If you’re working within the context of a form where someone needs to select a date, should you be developing a date picker that looks like a miles per hour gauge on a car dashboard with a little lever that you’re rotating in a polar coordinate like way? No, that’s ridiculous. That’s not a way to pick a date. Show me a calendar. Let me pick Monday on…The third Monday of that particular month. It’s an established way that people already recognize and can really accomplish successfully.
There’s a reason patterns exist. Hopefully it is to heighten the usability of a lot of the different solutions that we create. It really is not that the designer is less creative, but they’re exercising judgments to adopt the conventions that they can use to their benefit, like a header, like a calendar picker. And then apply their design critical thinking to the areas of, “Should I really use two date pickers next to one another? Should I have these on successive pages?” Really, those kinds of choices end up tailoring the use of those patterns to the specific problems at hand.
Adam: One of our audience members wanted to know if he could contribute features to Block, since its sources are available on GitHub.com.
Nathan: Oh, that would be a dream of ours. I think, just like with EightShapes Unify in 2009, we had a lot of folks that contributed patterns of pages that people would use in .pdf deliverables. We tried to incorporate those and it was a lot of fun. But it’s really not our expectation. If the community uses the tools, some people download this and find it useful and they’re interested in extending it, by all means.
The thing that I probably have less experience with is how to coordinate those contributions and the interesting part of the journey, for me, and I think for EightShapes in general is treating it like a product, right? This thing has features. This thing has priorities. This thing has phases that we need to really release it out into even our own EightShapes community of designers to use on projects.
Some things are stable. Some things are experimental, but being able to address that over time has been a much different challenge than working on design services contracts that are fairly common within our culture here.
But you know, I’d be interested to learn from, and even incorporate, the good ideas that arise so if you have them, don’t be shy.
Adam: That’s awesome, Nathan. Thanks for joining and circling back on some of these great questions from our audience. For everyone listening in, thank you for your support of the UIE Virtual Seminar. We appreciate you joining us.
You can get all the details on upcoming seminars at UIEVS.com.