Jared Spool: Welcome everyone to another episode of the Spool Cast. I am Jared Spool. And I am here today with Mark Burrell who just gave a fabulous UIE Virtual Seminar with Peter Morville called Leveraging Search and Discovering Patterns for Great Online Experiences.

Peter went on and on and on about the theories of search and the different ways people search but Mark got into the real meat of the session. Don't tell Peter but I think his part of the session was the best.

Mark is the worldwide lead for User Experiences Endeca and I don't know if you know about Endeca but they make these very cool, high-end, search products around guided navigation and faceted search.

A while back we had Pete Bell and Daniel Tunkelang who were both from Endeca speaking on faceted search. So, it's been very popular. This particular virtual seminar that we did was our highest selling virtual seminar for a really long time. So, it was really very popular.

Mark did a fabulous job talking about the work he's been doing behind the Endeca UI Design Pattern Library. And we've got a whole bunch of questions that didn't get answered in the session. So today we're going to answer them and I got Mark right here to do it. Mark, how are you doing?

Mark Burrell: I am doing fine.
Jared: Excellent. Let's get into these questions because they were really, really interesting. Now, during the presentation you were talking about different ways to bring search options and in particular facets to the surface.

And one of the ones was using sliders, Kayak for example, the travel site, that you used sliders to narrow the number of results that you get back from your initial research to say, well, I only want flights that take off between 10 in the morning and noon, or I only want flights that are going to land at my destination before five p.m. And so they use these sliders to do it.

But my experience is that sliders though they make a great demo, they're not always as intuitive as they should be. Is that what you found?

Mark: I think that's true. I think this is a great example where the devil is in the details. So, the concept of a range slider, particularly with histograms that show the distribution of what's available, depending upon where you set your minimum and max, that it's a very attractive concept. But if you don't get the details right, you can actually have problems.

So, I'd say as I would say with a lot of things it's not that range sliders with histograms are uniformly intuitive. It's that if they are designed well and you pay attention to the details of the design elements and follow some principles they can be extremely intuitive.

And just as an aside we don't have a vast body of usability results on sliders. We have several studies we've done and actually a study that our customer has done on specific applications that use range sliders. And the one with the customer I'll just mention as a small one. But they did independent testing, we didn't even do it.

We designed a range slider which is actually visible carzone.ie and they reported to us that when they did an independent testing that across the site and there were several other things in that application but there was a 95 percent success rate across all scenarios and tasks in a usability study.

So, again, this isn't hundreds of people but it's the very solid usability testing. And we've done some internal testing as well. And we use range sliders in a number of applications and they have tested very well. But to go back to my point about devil is in the details is that... Jared I can go through with some of the details there? That will be valuable.

Jared: If you want, yeah.
Mark: Why do we even consider range sliders with histograms? Why is it suddenly an attractive concept? We got the ideas that, depending upon what types of facets you are presenting the idea is to present them in a way that is intuitive and that is maximally efficient for users. So, the way you present the facet should match to the type of facet, the type of user, and the type of interaction you want to have.

So, historically, if you look at a lot of quantitative ranges as a facet that are exposed on e-commerce sites, and we have these on analytical applications as well, the old way of doing it was really just to set up these discreet ranges, you know it's between $15 and $75, between $75 and $100. And you select one at a time.

And in psychology we know that in order to really get people to quickly understand something, the way you present something should be matched to the type of information it is.

So, range sliders are a natural. It's really what people are trying to do is set a minimum and a max, or why don't you give them an affordance to do that. So, it's very attractive.

Some of the details are really critical though or actually UI text is very critical, how you label it. I know people say people don't read but really labeling the minimum and max, providing people with feedback as they move the sliders, designing the elements of the handles so they really have an affordance of grabability and so on.

If you do all of those details very effectively you can make range sliders with histograms very, very intuitive and the extra value, the reason why I mentioned the histograms is because it also lets people peek around the corner.

So, the example I gave in the webinar was... I am looking for used cars and I set my range at $7,500 for a certain type of car and with some parameters around a year. Well, the histogram will show me that if I just increase my maximum a little bit you might have about another thousands cars.

If I spent $7,700... So really it helps people peek around the corner and it's a fantastic way to get people actionable information set. And some, they can be extremely intuitive, they're designed well. They have multiple advantages over other ways of presenting quantitative ranges.

And I'll come back to this issue later on Jared, because when you have other types of facets, the same principle applies. You show the facets in a way that it matches to the type of facet it is. If you're showing colors, don't just list color names, actually show the colors. If you're showing body type for cars people will make very visual distinctions. Show them schematics of the body type. It's all of those things. In some ways it's all part of the same underlying principle.

Jared: That makes perfect sense to me. The fact is that language only takes us so far and oftentimes in business we apply words to things like body types. So, what it's the difference between a coupe and a sedan? That everybody inside the business is going to instantly know because we live and breathe that stuff but on the outside that gets us into trouble.
Mark: Absolutely. And then there are cases that not only get us into trouble because the way to convey that we all know a picture is worth a thousand words but we don't always operate that way.

Not only it is that words sometimes don't best convey the nature of the facet and the choices that people have but sometimes it's actually in conflict. We looked at an application for example where people were able to refine by color. And so you had a list of colors and the links were blue in the guided nav. So you were reading color names that said black but the link was in blue.

Jared: Oh that's funny.
Mark: And actually for those people, the listeners who might have a psychology background there is actually a phenomenon in psychology that's referred to as the Stroop effect.
Jared: Right.
Mark: It basically means if there is a conflict between two aspects of information, the word and the color for example, it dramatically decreases reaction time. Basically, you are creating a little cognitive task for people to figure out.

Those are the unintended conflicts but I think your point about we tend to default to using words because we know what they mean. Well figure out the best way to present it to people, visually and otherwise, so that it aligns with their mental models and what it might mean to them. I think that's a good lesson.

Jared: You are absolutely right. So, we've got another question, which had to do with looking at different solutions for different audiences, being able to optimize for different audiences at the same site.

So, for instance Jeff asked if in an enterprise search they should use different patterns for different types of problems and should their scientists have a different set of solutions in the design than the marketing people have. What's your take on that?

Mark: I think these are fantastic questions. I addressed it a little bit in the webinar.

We like to say one size does not fit all. So, the framework that I showed during the webinar was, you really need to look at your audiences and what they know and how they interact with information, as well as what their scenarios are. Are they looking for something specific, or are they trying to learn something more broadly and explore a space they don't know about and have learning objectives?

Very different types of users and very different types of scenarios. And the questions are absolutely spot-on, that you need to consider that when you select design patterns, when you create design patterns, and when you ultimately design your site.

The first thing I would say is that, for different types of audiences, you often need a different interface. The best example I can give you and where people can look on the web to see examples of this is, you'll see, left-hand guided navigation, what we call vertical stack, with expandable and collapsible menus. The facets are presented very efficiently but they're not all exposed at once. And there's sort of a sidebar. Carzone.ie is a good example of that. Home Depot is a good example. Got lots of good examples, across every domain.

I like to refer to that left-hand, vertical-stack option as the "Swiss Army Knife" of guided navigation, or faceted navigation, because it is explicitly designed to deal with very different audiences. It actually can work fairly well for both the knowledgeable seeker and the uncertain explorer--the person who really knows their domain, they know what they're looking for, they want a lot of details, and the uncertain explorer, who really doesn't know a lot. Or the uncertain seeker: they know what they're looking for, but they don't really know a lot about the domain.

Left-hand guided navigation--and I think we'll refine that with some good, really solid design elements to make that more and more effective--the reason why that's so widely emulated, I believe, is not just because there haven't been alternative models out there, but because it really works very well across varied user segments.

However, we know that it's not optimized for certain segments. So, for example, if you're dealing with engineers who are making decisions about electronics components and parts, and they need to look at the trade-offs between, "Well, if I select this resistance over here, what does it do about the weight of this power supply?" And they need to kind of see the trade-offs. It needs to all be exposed. They're very knowledgeable about the domain. And they need to look at the relationships between the facets. That's a very different type of need.

When you present left-hand, vertical stack with most of the dimensions closed or only one open at a time, only facets exposed one at a time, they can do it, but it's not really optimized. That's why you'll see, on some sites, a pattern that we've called open-horizontal guided navigation, or facet navigation, which shows the facets exposed along the top, and the results are below it, and as you make changes to one facet, it dynamically updates the other facet right before your very eyes. So you can do that kind of trade-off analysis right in front of your eyes. Because the engineers, they need it. They can do it.

So, I think, to go back to the original question, to optimize it for different audiences, you often do need different patterns. Sometimes you need to. And everyone, I think, who does UI design knows this, that very often you have numerous audiences who are using a site, and they're all high-priority. And sometimes you have to make trade-offs and say, well, we know it's not optimized for this group, but we're going to use this because it's the Swiss army knife.

But on the other hand, if you look at a lot of electronics-components sites, as an example, they actually have the same problem. They have electronics engineers coming to their sites, places like RS Components and Premier Farnell. They have engineers coming to their sites. And they have buyers, who really may not even know what they're looking for; they just know the engineer told them to get the part, and they just need to find it. And by the way, what if the part's not available? They've got to go find it. Their heads explode when they look at that open-horizontal guided navigation. But you might just decide, look, we've got to optimize it for the engineer.

The thing I would add is that, ideally, in a really personalized application, if you knew something about who the people were who were coming and what their scenarios were, you could actually create a very personalized experience so that if I'm a buyer, I come and I actually can explore in a very specific way that works for me, and if I'm an engineer, I see it another way.

We've also experimented with a couple of applications where we've enabled people to toggle between different views, different ways of working through the faceted navigation and refinement process. But I think that's still pretty new and under development. We don't want to confuse people. But I think personalization, actually based on the user role and their scenario, if you know what their scenario is, I think that's really a great option for optimizing the experience for different users and different scenarios.

That make sense, Jared?

Jared: That makes perfect sense to me. One of the things that was interesting in Jeff's question was he did say, "Should our scientists have a different pattern than our marketing people?" But it's really not about the people. It's about the problems, right? It's about the things you're trying to do. So it's very possible that marketing people may need different patterns, depending on what they're trying to solve.

Mark had a question which was very similar to that, which is: sometimes he needs a very definitive search for results, and sometimes he just needs a good answer. He says, "I need to know all my parts that I source to a particular to supplier." So he needs to know that the search results have gotten everything. And that's sort of similar to the electrical engineering example gave, where you need to know what the ramifications are of each result.

Are there different patterns that fall into play when you're dealing with that "I need to know the complete set of data that's in the database" versus "I need to know the best thing that you could possibly find me, but not everything"?

Mark: Absolutely. Absolutely. To some extent, it is the example I had in mind. If I'm a manufacturing company and I make cars, and I need to make sure that we can find a small set of side-view mirrors that we can use on all of our programs and source them from the best suppliers. I need to know all of the side-view mirrors we use and all the suppliers. It gets back to your point about what's the problem. Who is the user, and what's their problem?

It actually dovetails with a question I get very often, which I think there's often not a very satisfying answer for, which is around things like edge counts, what we call record counts, showing that little information scent around the facet that shows you how many results you get. Frankly, in a lot of e-commerce contexts, what we find, and what my observation is in the testing I've done, is that the specific numbers often, in many scenarios, are unimportant.

People use them very broadly. What it does is it conveys, hey, this is different. There's something behind here. And if I'm going to make a choice between going to something that has over 1,000 results associated with it or something that has 2, I'm probably going to put the filter on that has 1,000 because I don't want to dip in and out. It gives me the best chance of being successful. But it's used very roughly, to give rough order of magnitudes and to convey that there's something different and to be a call to action.

On the other hand, the example that Mark gave is a good example of how things like record counts are often the thing that these people are looking for. If that's the case, then showing them parenthetically is important but not enough. For those types of users and those types of scenarios, you actually may want to make summaries about the data set, not just the individual items themselves, very prominent in the UI.

So, for example, breaking out how many suppliers there are, putting that in the results table. There's actually a results table that shows you that. Or using what we call analytics, summarizing things analytically, how many you have, and then graphing then visually and showing people visual graphs. You can see some of that on sites like, a very different domain, but newssift.com, which actually was taken down recently. But you can see that on certain sites, where there are charts that are showing the sentiment. That's probably one of those where I want to back up a little bit.

But I think the idea is that if people have very specific needs to know something about the data, rather than just looking at the items themselves, we need to find other ways to summarize that data and present it to them, both in textual and visual forms, so they get their answers. Make sense?

Jared: Yes. So the example is sort of like the way Amazon presents reviews, right? You can click on just the five-stars or the one-stars, right?
Mark: Exactly. That's a great example, I think.
Jared: Yeah. And it's a histogram, so you can actually see that there's a lot of five-stars but only a couple of one-stars. You know the moment you click what you're going to be in for in terms of data.
Mark: Right. I think we can start to riff on a lot of examples. People have seen the notion of tag clouds, which very often are, in my view, not really used effectively. There have been some sites where it's been used fairly effectively, like Bazillions used them for a while to let people look at the key terms in reviews, not just ratings. But I'm looking at a camera, cameras with a certain set of characteristics, and I see a tag cloud that says "best uses versus cons." And I can see, oh, in best uses, it's "outdoor rugged." Oh, I want to see the ones that people say are really good for rugged.

Or you can think about, if I'm a medical researcher and I find three million articles on asthma, but I can also see a tag cloud that shows me thematically some of the key terms in there, and I see clusters that "cockroaches" and "poverty" are in large text and they're associated with each other, well, that actually helps me with my analysis.

So the idea is determine what information is critical for the people that you're designing for, and make sure that you make that salient, in a way that matches to what the information is. I think that's kind of the key lesson.

Jared: That makes perfect sense to me. Along similar lines, Lisa asked a question about Intranets versus Internets, and are there differences there such that you want to, on an Intranet, expose the problems that search is helping with. She says that she's under a lot of pressure to just put search on her Intranet and make it just be like Google, one big search box that just magically knows how to deliver the results. But does that really work well on Intranets, do you think?
Mark: People in enterprises tend to think differently, at the high level, about Intranets versus Extranets and external websites. But I actually think that the process that we're describing and the way you would design for it is almost exactly the same.

I know that pressure to just make it a search box. To some extent, you're dealing with, potentially, a smaller set of assets, although that's not always true, depending upon what you expose on Intranets. I'll give you a couple of examples.

We worked on an Intranet application that was for the 350,000 people who worked at one of the largest retailers in the world. There was a place that people needed to find HR information, human-resource information--sorry for the acronym.

But imagine that I'm a person who is on the floor of a store, and on my lunch break I've got to go find a dental form. I've got to go to the dentist. Or my wife is sick and I need to think about family medical leave. Do I qualify? Or I'm an HR manager and I need to know what policies have changed. I'm a content creator and I need to make sure that people are getting the right information. And I'm manager and I have a problem with an employee, I need to know what the right procedure is.

So, I'm giving you those examples because we had to design an HR knowledge base that worked for all of those people, and it wasn't a search box. We actually used one of our patterns, which was mixed results with spotlighting. We designed dynamic landing pages, and we used personalization. So we had faceted navigation for all, search with look-ahead.

We spotlighted different types of content from the results for different people. So if I did a search for "dental, " if I'm the person on the floor, I might get 300 results, but on the right-hand side in a little spotlight zone, a little box on the side, it pulls out: these are all the forms related to dental. But, if I'm a human-resource manager, in the box on the side, I don't get the forms. I actually get: these are the recently changed documents and policies related to dental coverage.

So the idea is that was where we had to find one of those Swiss army knives of patterns that worked for all.

On the other hand, you can think about, Intranets have very broad scope and very broad problems. So if you're a company that has an R&D group, a research-and-development group--a pharmaceutical company, a manufacturing company, et cetera--and you're trying to provide a way for them to explore information from their database, from the news, from research articles externally, and you're pulling it all together, well, that design may not work for them.

So you do need to think about how to design for the marketing folks and the scientists and so on. But I think it's the same process, Jared. It's really kind of thinking about, what do people need to know, what assets would be useful to them, how do they need to interact with them, and what's the best way to present it to them?

And if I need to design for multiple audiences and multiple scenarios, what's the best compromise, or how can I make it really slickly personalized so that I can make it work great for everybody and not make any compromises? It's the same process.

Our user-experience team does as much work internally as externally. And if you saw the way we went about the work, I'd say it's almost identical.

Jared: That's interesting. There's a lot of thinking out there about how to keep things going from being too complex to too simple, breaking stuff up into useful chunks. And sometimes the divisions we put on things, whether they're Intranet versus Internet, whether something is B2B versus B2C, those sort of high-level classifications really don't describe the lower-level, mechanical things that we're trying to solve and problems that are there.
Mark: It's not to say that there aren't important differences between the domains, but it's not at the level that people think.

So, for example, when you're designing something inside the enterprise, you actually have an advantage that you often don't have when you're dealing with external, customer-facing sites, because you can know a lot about who people are. They have to be authenticated. So you actually may have many more opportunities for personalization, which you may need to change a little bit of some of the design considerations and solutions. But fundamentally, it's the same thing.

I just want to point out, it's not that there aren't differences. It's that it's not "We need a fundamentally different solution for an Intranet versus..." You've got to go down to the next level of detail and say, who are the people, what are the assets, and what are the opportunities and challenges?

Intranet has the opportunities that you potentially know a lot about the people and their history and the things they do and who they work with. And you can use all of that to really create a fantastic, personalized experience. Sometimes, with external websites, you're kind of flying blind. You don't really know if it's a buyer or an engineer or my grandmother. You just don't know.

Jared: Right. That seems exactly right to me.

Tara asked an interesting question, which had to do with sort of bridging the gap between search and browse. She says she keeps trying to merge the two, particularly when she's working with her clients, which are big information publishers. She wants to expose the taxonomy with search criteria, but then have people use auto-suggest and pick lists and stuff like that to make browsing part of the search process. But she's concerned that she's making that a little too complex. Are you seeing that work, combination approaches?

Mark: Yes. But again, it's similar to what I said about the range sliders with histograms, Jared, that it can be done poorly, or it can be done very effectively. [laughs] We actually encourage people to really break out of that model. And I think of the kinds of things that Tara mentioned, around auto-suggest.

Let me give you an example. If you go to a site like ranger.com or sonystyle.com, or a bunch of other sites, you'll see. There are a lot of sites. Newegg.com. You see a lot of sites that are using auto-suggest, what we call look-ahead, with dimension search.

But one of the key differences is that that can be done very poorly. If I start typing in a search box, and after I type two letters I get a list of 25 items, and it's all keyword matches and it's all over the map, well, I don't think you've really helped me. Unless there's something at the top of the lists that's really right on-target, by accident, you've actually now given me the task of scanning through a list of 20 items that may be not totally randomly, but very tangentially related, because it's a keyword search.

On the other hand, if you say, when people type, after three or four, depending upon what makes sense, I'm going to recognize, "Is this a part? Is this a book? Is this a product? What is it?" And I'm going to now make matches to categories of information, and I'm going to group them, and I'm going to show you little visual icons or pictures that help you quickly scan a very short list of five to seven items, and it begins a dialog.

In the testing we've done, that's been extremely effective. But again, the devil's in the details. So there are a lot of elements, like match the categories, group them, don't do too many.

The broader comment I would make--and I know Pete Bell and Daniel made the observation as well--is really think about it as a dialog. It's not merging search and browse, really. What it is is it's actually a relatively new paradigm that's saying--just think about a dialog. You go into a library. You don't just go in, and you're not surrounded by two and a half million books, and you don't just scream out, "Psychology!" and suddenly...

In this universe, you now have the opportunity to actually have a dialog with your users. So it is a little bit like going to the librarian and saying, I need to do a term paper on the economy in China. The librarian would then get into a dialog with you about, "What about the economy in China?" and blah, blah, blah.

The idea is, I actually think it's not more complex if it's done well. It actually aligns very well with human dialog, and it's actually more natural than search. Now, that may sound wacky and counterintuitive, given the fact that search has become a fundamental part of our lives--we've all been Google-ized. But I think more fundamental is human dialog, and I think the more we can approximate dialog, the better.

I don't like to use that phrase, but if we think about merging search and browse in the ways that Tara is pointing out and that I'm talking about, it really becomes more of a dialog, making suggestions: Did you mean this? Let's disambiguate what you just said. I want to be clear and get you to the right stuff. That is really the model that we should move towards.

Jared: I wonder if there's a sort of conservation of complexity that happens because, if you make it a great dialog and you make it feel very natural for the user, it becomes simpler for them, but to do that actually increases a lot of complexity for the developer and the designer. I'm wondering if complexity is always somehow conserved, because the simplest designs for the developer and the designer turn out to be the most complex things for end users to deal with.
Mark: I think you make a couple of good points there, Jared. One thing about it, the complexity for developers, to some extent, depends upon the underlying technology that you're working with. If the technology wasn't designed for that dialog, and then you're going to be kind of building all that manually, that's a lot of manual work. It really is.
Jared: Right. So good tools play a huge role.
Mark: Absolutely. And not a pitch for Endeca, but in the way that we've architected our platform, we designed for that, so that makes it a little easier.

But I think you're actually right. I think you introduce the need to make a lot of design decisions that people have never had to make before. I think they're actually important decisions to make, but they are design decisions.

I like to talk about, designing for this kind of dialog and faceted exploration, and faceted discovery, which is the way I prefer to talk about it, really requires design off the screen. What are we going to match it to? Which dimensions are we going to match it to? When are we going to start to match, after three or after four? How many are we going to present? How are we going to group them? How are we going to recognize whether or not they're typing in a product ID number or a coupon code or some keyword, free-form word? There is a lot of complexity there.

To me, those are the right decisions to make. And you know sometimes the things that are the simplest for people, and that look like they're just so elegant and simple, sometimes have a lot of design work behind the scenes. So I think that's a fair comment. I think it's worth all the effort because, at the end of the day, if you do it right and it accelerates discovery, it's good for the users and it's good for the organizations you're working for.

Jared: Along the lines of complex things, Luigi asked a question. He says, "Sometimes it's more useful to combine facet values in a disjunction," which, in essence, is an and, "and sometimes in a conjunction, which is basically an or. The problem is, how do you make those funky query things easy to understand in a visual display? How do you make it clear that the actual and-versus-or types of things are happening there?"
Mark: I think it's another excellent question. There's kind of a couple layers of complexity here.

So the first thing is, when I click on a facet, however it's presented--is it presented as a picture, is it whatever--how will the user know whether or not that's going to create an intersection, which is the and, with your other filters, or if it's going to actually start expand. Is it refining or expanding? That problem, I think, is actually fairly easy to solve.

We have a pattern that we call multi-select, which is our geeky term for creating unions, or what Luigi called conjunctions, the ors. The easiest place to observe that on the example on the web is go to carzone.ie. The key element is, use an affordance that at this point is recognized as expansive.

Think about GUI conventions that people have learned. And this is a moving target. That's another thing to note. How you would design this to make it understandable to users has to accommodate people's experiences with graphical users interfaces and the ongoing conventions on the web and off-line. But you know what? We actually have a pretty good convention of this that my grandmother would recognize, which is the difference between a radio button and a check box. It's used everywhere. So, check boxes, oh. So I can select more than one. Fine. So that's kind of the simple part of it.

One of the questions that I sometimes get about it, though, and I think Luigi had actually asked about this, too, is should we give people the option of applying it as an intersection or as a union? At this stage of the game, I'd say my recommendation would be not. Imagine going to carzone.ie and I can say, "Find me all the intersections." Sometimes it just doesn't make sense, which is pretty obvious. But it also creates a lot of complexity for the user. And frankly, you're probably better off enabling that multi-select that I talked about because it still gives you the intersection capability.

But we've actually looked at one application that a customer did where they tried to do both and let the users kind of toggle between the two. And it was extremely confusing, and actually, they reported it tested extremely poorly, and I would have predicted that.

There's a very simple way to convey the fact that you can create unions by putting facet values together, filters together, and that's using an affordance like a check box. There are probably others, but that's probably the most common one today. I would not put them together in the same facet or dimension. I wouldn't say to the user, "You can apply this as an intersection." I can find all the intersections between BMW and Mercedes. Well, that doesn't really make sense. But beyond that, even in situations where it made sense, you would create a new design problem to solve, which is how do you convey to people how a filter is being applied.

We actually are starting to work on this problem. And I think we'll see it in the next generation of faceted exploration, because we're doing a little bit of this in some of the behind-the-firewall applications we're working on, but it hasn't been exposed publicly, being able to create complex combinations. In a human sentence, you could actually say, "Show me all the cars that are between $5,000 and $10,000, they're minivans, and I like Hondas and I like Fords." We can do that today.

Another interesting thing is, "I like Fords, but I hate Toyotas. Can you exclude the Toyotas, please?" There's also the possibility to start to enable people to invert filters, or use them as negations or exclusions, and to create complex combinations. But unless you have a good visual way to represent that that people can toggle and a good way to enable people to represent it in a breadbox so they know what's going on and so on, that's an order of complexity that most people are not ready to address. We've done that in very small ways.

Let me give you a real-life example, which is, imagine that I'm an enterprise sales guy for a computer company. I'm looking through all my customers and I want to know, "Who are all my customers who bought Windows 7-ready laptops and desktops but they haven't bought Windows 7?" It's a very understandable human sentence, and it's actually a very simple scenario from the user's perspective. But unless you have a good visual way to represent that in terms of visual controls and interface and a way to summarize it, you can really, really confuse people. But I think that's coming. We're working on it.

Jared: Speaking of things you're working on, you've got this project that's been like your life goal here: the Endeca UI Design Pattern Library. How is that coming along? That should be available soon, yes?
Mark: Yeah. Well, I don't know if I'd call it my life project. We've been working on it for a couple years. We're expanding to new patterns all the time internally, at a rate that we think is pretty fast, but never fast enough.

We are planning on making a public version of that available. We'll always have things that we're working on behind the scenes that we don't think are ready for prime time. We don't want to wait until things are always fully baked. We like to throw things out into the marketplace. You wait too long, then people have already moved on to new things, [laughs] and they could have benefited from just the ideas.

So we are going to come up with a public Design Pattern Library. We're just waiting to implement a web content-management system and kind of go public. So I don't have a specific date, but it's coming this year, Jared. And if people want to be alerted to when that will be made available publicly, they can email patterns@endeca.com, and we'll put them on a list and they'll be the first to know.

Editor's note: It's live now, find it here: The Endeca User Interface Patterns Library.

Jared: We'll post that on our blog and sign up for the list so that when we know, we'll let all of our friends know.

Thank you very much for answering the questions that were from the seminar. And those who want to hear the seminar, it's available on our website: "Leveraging Search and Discovering Patterns for Great Online Experiences" with Peter Morville and Mark Burrell. Peter also answered a whole bunch of questions in a separate podcast, and so you can hear that, but as I suspected, Mark's answers were better.

Mark: [laughs] Hey, did you say that to Peter when you spoke to Peter?
Jared: No, I don't like to let his ego get so big.
Mark: OK.
Jared:[laughs] Mark, thank you very much for spending time with us today.
Mark: You're welcome. It's a pleasure.
Jared: And I want to thank the audience for spending the time, and I want to, again, thank them for encouraging our behavior. We'll see you next time. Thank you very much.