Findability is a filtering problem. There is a whole whack of stuff on the Web. To find what you want, you have to filter it. So if you can provide your visitors with a more sophisticated filter, such as a faceted navigation or a taxonomy-based browsing experience, they will have more success finding stuff, right?
Not necessarily, no.
It’s easy to get caught up in the functionality of finding mechanisms. Functionally, the key thing you want in a finding aid is discrimination. It should be able to tell the difference between things and allow the user to select one thing and not another with a high degree of accuracy.
A site like autocatch.com provides great discrimination through its used car selection mechanism.
- Faceted navigation can provide highly discriminating results.
If you are looking for a 2010 Subaru Impreza Hatchback with manual transmission in Ottawa, Ontario, the site’s highly discriminating faceted search mechanism will let you focus right in on the one vehicle that is available for sale that meets those criteria.
There is no ambiguity in those results, and no distracting irrelevant content to wade through. Wouldn’t it make sense to implement the same kind of system to help users browse your content?
Not necessarily, no.
There are a couple of reasons for this, the first of which is one I have discussed before. When users go shopping for a used car, they know that the kind of car they want exists. They don’t know for sure if a car that matches their particular wish list is available for sale in their area, but they know what features they are looking for and they know that cars with those features exist. The objective of their search is clear and concrete in their mind’s eye.
When someone is looking for information, however, they don’t know with the same degree of certainty that a piece of content exists that contains the information they want, and they don’t know what such a piece of content might look like or what it might be called. There are some exceptions to this, such as when the user is looking up a known function in a known function reference, for instance. But by and large, a searcher knows far less about the content that might answer their question than a car buyer knows about the kind of car they are looking for.
What happens on autocatch.com if you enter a fuzzier search? I searched for “car that’s good in winter”.
Here’s the result:
Yup, a $40,000 Porsche would be my first pick as a good winter car. Further down the list there is a $33,000 Mustang GT. (My guess as to why these show up is that up here used spots cars tend to be advertised as “never winter driven” — meaning never exposed to road salt.) By contrast, here’s what you get when you type the same search term into Google.
Sometimes a fuzzier search yields better results.
So, while it is great in theory if your navigation system is highly discriminating and highly specific, it may not work so well unless your readers are equally specific and have a really clear idea of what they are looking for.
But it’s not just that. Part of the problem is that that sophisticated search system just looks complicated. Even if it works really well, that could be a problem. In his blog post The Third User or Exactly Why Apple Keeps Doing Foolish Things, UX guru Bruce Tognazzini argues that Apple does a number of things with its interfaces that make no sense from a UX point of view:
Apple keeps doing things in the Mac OS that leave the user-experience (UX) community scratching its collective head, things like hiding the scroll bars and placing invisible controls inside the content region of windows on computers. Apple’s mobile devices are even worse: It can take users upwards of five seconds to accurately drop the text pointer where they need it, but Apple refuses to add the arrow keys that have belonged on the keyboard from day-one
So how is Apple so successful, and how does it enjoy a reputation for ease of use, if it makes these kinds of UX mistakes. Tognazzini argues that Apple is focusing on a user that most UX people neglect: the buyer.
What do most buyers not want? They don’t want to see all kinds of scary-looking controls surrounding a media player. They don’t want to see a whole bunch of buttons they don’t understand. They don’t want to see scroll bars. They do want to see clean screens with smooth lines. Buyers want to buy Ferraris, not tractors, and that’s exactly what Apple is selling.
Even though useful UI controls are missing from the interface, it looks simper to use to the buyer in the store because there are fewer scary-looking controls. They may be useful to an experienced user, but they are scary to a buyer. Tognazzini draws a diagram illustrating which user’s get the attention of Apple and the UX Community respectively:
The UX community fails to consider the buyer. Image courtesy of Bruce Tognazzini, used by permission.
For UX Community, we could easily substitute tech comm community, though for tech comm we should probably fade the bar to white at the expert end of the spectrum, like the Apple bar does. Tech Comm tends to be overly focused on novices. Certainly tech comm, often quite adamantly, prefers not to have anything to do with communicating with buyers. There is, in tech comm, something bordering on disdain for marketing and all its works, something which Sarah O’Keefe has been campaigning to change for a while.
But here’s the problem with not wanting to deal with buyers: when it comes to the documentation, the user may be an owner of your product, but they are still only a potential buyer of your content. They have multiple options for finding information, including giving up and not bothering.
Ultimately, the buying decision they make about information sources can make a significant difference to how much they get out of your product, and therefore if they will buy it again or recommend it to others. But they are not a captive audience. They have not bought in to the idea that consulting your content is the best use of their time. You have to sell them on that. You have to treat them as a buyer, not a user. And as a buyer, they probably don’t want to see all kinds of scary-looking controls surrounding a doc set. Something like this, for instance, does not exactly scream “easy to use”:
A help system with this many controls is not likely to appeal to the average information buyer.
Combine the scary huge table of content with the fact that I am apparently expected to take a short course just to learn to use the help system, and this is not the information buying experience I was hoping for.
Or how about this:
Now I have something else to learn, and my head is still full of the original problem I was trying to solve. By the time I have figured out how to use this, will I still remember what I was trying to do? The question isn’t whether these interfaces work. It isn’t whether, if they were used properly, they would do an excellent job of narrowing down the content to the thing the user was looking for. The question is, confronted with something like this, that looks so complex and so foreign to the things I know about, am I even going to bother trying to use it? As Jakob Nielsen notes:
In general, we almost never see people use advanced search. And when they do, they typically use it incorrectly — partly because they use it so rarely that they never really learn how it works.
So, the functionality of your elaborate finding aids may be top notch, but will anybody use them? And if they do, will they use them correctly? There are, of course, two finding and navigation aids that everyone knows how to use without having to think about it: basic search and links. We know that people are very search dominant in their behavior. We also know that they are not very good at searching. According to Jared Spool’s research, though, they are much more successful using links.
It follows that if your want your users to actually find things, you should probably be putting more effort into making sure that your content links richly and accurately. All too often, the user enters a site via search, which they don’t use well, and finds themselves at a dead end: a page without any useful links. Good linking, which people both use, and have success with, can change an unsuccessful visit to a successful one.
Before we get too carried away with complex finding aids, therefore, we should stop and think about the user as a buyer. If the finding aid is a perfect match for the user’s expectations — if its facets are the facets that the user already has clearly in mind before they arrive at your site, it may be worth while. As Nielsen notes:
if you have a well-designed search facility, and users are looking for a specific item with a well-defined name, they’ll probably be successful. In our testing of search on e-commerce sites, users found what they wanted in their first search attempt 64% of the time. And their overall success rate with search was 74%, which is pretty good
But if not, users will likely rely on basic search and linking. So what can you do to make them more successful? Two things:
- Create good Every Page is Page One topics that establish their context so the reader knows where they have landed, and that fulfill one purpose for the reader.
- Link those pages richly along lines of subject affinity so that readers can refine their location in your information and easily find ancillary and background information on what they are reading.
Mark, interesting post. I love the discussion that’s going on around faceted search. I’m actually reading through Robert Glushko’s The Discipline of Organizing right now. He says that for information resources, the best facets are those that describe the information’s “aboutness.” Rather than resorting to physical attributes like size, weight, shape, etc., couldn’t you have facets based on aboutness, which are familiar aboutness categories for a specific domain?
Re looking for cars in winter, the faceted search should be based on the kinds of terms the user wants to look for, right? If so, maybe a seasonal facet would have been helpful.
I agree that the facets need to be terms the user is looking for. I just think that trying to come up with facets that reflect physical type attributes may not be the most productive route. I think instead we should use the aboutness attributes.
Mark, I agree with your writing approach and your posts always give me something to ponder. For what it’s worth, maybe this can give you something to consider.
Last month, at the CIDM conference, Antidot demo’ed their Fluid Topics product. It was very slick and one of the features was around full text, google-like search. I don’t know the product or how it works (behind the scenes), but it sure showed nicely and gave a great user experience over a large documentation set. I’m sure they would give more info .
Karen
Thanks for the comment, Karen.
Everyone seems to be recommending I look at Fluid Topics these days. It’s hard to judge a search engine without some real purpose, but it seems pretty clear that no captive search can ever match Google, simply for lack of sufficient data.
The scrolling TOC thing is technically interesting, but only if your content is still book-like. Of course, many people still have and produce book like content, so it may appeal to them.
Thanks for the comment, Tom.
I certainly agree that if we are going to use facets for information discovery, they have to be based on “aboutness” — at least if it means what I take it to mean, which it that it should be based on what the user has in mind when they are looking for information.
But if that is going to be the case, then the information itself needs to have a consistent aboutness, which means not merely having aboutness metadata attached, but fully meriting that metadata. (This the the metadata issue we tossed back and forth a while back.) For most people, that is going to mean they have a ton of content work to do before they are ready to set up their faceted navigation.
That, in its turn, means that we would need to create a matrix out of all the facets we plan to use, and then create topics/docs/pages at all the intersections of that matrix. That is what Jonatan Lundin would have us do, but I don’t think content is that regular. In particular, I think is the irregularities in the architecture, connectivity, and application of a technology that are the most interesting and most in need of documentation. Fundamentally, I think a web is a better model than a matrix for covering a subject as and how it needs to be covered.
Even if people do use the faceted search, however, they still end up at a page, and they still need that page to establish its context, and they may still need to navigate onward from that page to complete the information picture they need, so again we need links.
So I would suggest that at the very least what I am recommending — start by making sure your information set consists of good Every Page is Page One topics that establish their context, stick to their purpose, and link richly — is an essential prerequisite to establishing a workable faceted navigation based on facets of aboutness. So we need to do that first.
After that it is a question of whether people will actually use faceted navigation in preference to searching and linking. Unless the facets, and their values, are ones that the readers are used to seeing everywhere (like those used in retail) I suspect the answer will be no. But we have to fix the content before we are even in a position to do an experiment.
Should autocatch add seasons as a facet? The question becomes, how many such facets are there, and how much clutter would it add to the site to include all of them?
I think adding them would just make the site more forbidding. Again, simplicity trumps functionality.
Hi Mark,
I like the discussion about how faceted navigation/search could be used to enhance the search experience of our users. I believe that faceted navigation/search may very well enhance the experience, but as Tom points out, the challenge is not to build the system (the technology part is becoming mature, at least outside of techcom) but rather to know which facets that makes sense to users of technical products.
Your discussion about simplicity vs functionality is an interesting one and aligns very much to what I’m currently doing. I’m looking into the factors that impacts information source selection. We know that users prefer sources that are accessible, have high quality of content, are relevant etc (called the source preference criteria). But my question is how do users judge an information source, such as a faceted navigation portal, to be accessible? Your discussion implies that users would judge a simpler information source interface to be more accessible than an interface that is packed with advanced search functionality. You may be right, but I see that the judgment is far more irrational than users doing a rational comparison based on attribute evaluation.
User’s information source judgments are based on so many other factors. For example, “my boss have told me that the ‘simpler’ interface is useless and then I will not use it (I have never used it myself) since his judgment impacts my judgment”. One interesting explanation lies in what is called “mere attitudinal exposure” meaning that I get more positive towards an entity the more I get exposed to it. So if I get more exposed to a search interface that is more advanced than a simpler one, I would still select the more advanced one before the simpler since I have built up a feeling of “familiarity” with the more advanced due to the mere exposure.
And about the matrix: I firmly believe that we, as technical communicators, must first develop the facets and their values to populate the matrix, before we start to write anything. I see that the matrix can be used as a guidance tool to know which EPPO pages to write. The essential question is then what it is we are classifying: it is cars in the autocatch.com example, but what are we classifying?
Mark, would you agree that an EPPO page is an answer to a user question? If not, what content goes into an EPPO page? See my previous comment on idratherbewriting about predicting (some) of users questions based on a matrix kind of an approach where the user need is the starting point: http://idratherbewriting.com/2013/05/29/can-help-content-have-recognizable-facets/#comment-54619
I do acknowledge that many user questions cannot be predicted and that most user questions are not procedural, but conceptual by nature where the answer is needed to be able to take a decision: what does this mean? Where do I put this file? What data do I enter here? Can product do X? Why is product doing Z? Can I connect A to B? Where is icon Z located? etc.
Jonatan,
The notion of information source selection implies that there are multiple sources. I think it is increasingly the case that there is only one source, and that is Google. Information source selection is uncertain, and therefore mentally taxing. When we talk about technical communications, we are talking about people who are trying to solve a complex technical problem, and who therefore are already heavily taxing their mental capacity. So there is little mental capacity left for rational source selection, and for understanding of complex search interfaces. In these circumstances, I expect people will choose based on the least mental effort criteria, and that, for most today, means Google. This seems to jibe with research that shows people are increasingly search-dominant.
On the matrix, while I am with you on taking a metadata-first approach, I don’t think a matrix is a good reflection of user’s information needs. I think that the world is irregular, and it is precisely at the points at which it is most irregular that the greatest information needs occur.
You can always add facets, as Tom suggests, to encompass different requirements or interests, but every time you add a facet to a matrix, you increase the number of intersections exponentially, and soon you have to start pruning uninteresting intersections to the point where the matrix becomes more and more sparse. And while computers can navigate a sparse matrix just fine, the matrix loses any predictive value when it is sparsely populated.
I would agree that an EPPO topic answers a user’s question, but I would not define it that way. I would define an EPPO topic as serving a defined and limited purpose. I don’t see a matrix as a particularly promising way to predict those purposes, for the reasons given above. The best way to predict the user’s purpose it to be familiar with the task. I have also found that once you start to manage subject affinities in the topics you write, the unresolved subject affinities in each topic point to unmet purposes and guide you to what needs to be written next. (The theme here again is bottom-up.)
I’m wondering about the details of your page-linking strategy. Let’s say you have a “Gizmos” subject that has about 10 different topics. In topic 1, it might be natural to incorporate links to five of these “gizmo” topics but not the other 5. Do you put some kind of sidebar view that shows all links for that gizmo subject affinity?
For example, let’s say you’re writing about “Installing Gizmos.” In this topic, you have text like this.
/ begin
To set up your <a href=”http://helpsite.com/About_Gizmos”>gizmos</a>, you first must install ACME server and enable lib curl on your server. Once you satisfy those prerequisites, do the following:
1. Run the <a href=”http://helpsite.com/About_the_Gizmo_Package”>Gizmo package</a>.
2. Walk through the Gizmo wizard.
3. Copy the <a href=”http://helpsite.com/Gizmo_Settings”>gizmo settings</a> file to your root.
4. Chmod the gizmo folder to 777.
5. Configure preferences inside the application.
Once you have Gizmo set up, you can <a href=”http://helpsite.com/Incorporate_Data_Feeds_into Gizmos”>incorporate data feeds</a>, <a href=”http://helpsite.com/Export_Gizmos”>export your gizmos</a>, and more.
/ end
This page links to about 5 of the gizmo topics, but I haven’t covered the following:
* Importing Gizmos from a Previous Site
* Browsing the Gizmo Gallery
* Fixing Crashed Gizmos
* Backing Up Your Gizmos
* Changing the CSS of Gizmos
These other gizmo topics didn’t fit within the flow of the content. Do you have some kind of related links portlet on each page that rolls up all the topics tagged as “gizmo”?
Maybe your response is something like, if users want to do something, like alter the gizmo CSS, they search for that topic and find it, or at least another topic within that subject affinity, which will then lead the user to the right topic.
But what if I don’t connect into that subject affinity. What if I’m new to Gizmos and had no idea I could even change the Gizmo style. I also don’t know that I should be backing up my Gizmos. I’m also clueless about the existence of a Gizmo gallery. How do you help users discover these other Gizmo topics unless you enable a browsing mechanism?
Also, isn’t it onerous for writers to try to ensure each topic in Gizmos connects to a subject affinity via links to all other Gizmo topics?
If each topic that belongs to the Gizmo group appears in a little navigation portlet view on each gizmo page (kind of like a topic-specific navigation), then wouldn’t it also be helpful to make Gizmos a facet in your navigation or in your search results?
I reread your post on A New Approach to Organizing Help but couldn’t determine how you would answer the question.
Tom, part of the answer to your question is that you can have a more precise subject affinity than simply Gizmo (affinity to an object). You can also have an affinity to specific tasks such as “installing Gizmos” (affinity to task). Thus if you are doing something that requires Gizmos to be installed, your subject affinity is to installing Gizmos, and so should link to just topics on that subject.
Actually, affinities to tasks are much more valuable than affinities to objects. They are the affinities that tell you if you have got all the task topics you need. When you first start to manage task affinities, it is amazing how many relevant task you discover that have not been documented. This is one of the reasons I find the bottom-up approach more valuable than the top-down, populate a matrix approach.
Even so, there will definitely be affinities that resolve to more than one topic. While you want to monitor these, to make sure this is not a result of overlapping or duplicate topics, it is often legitimate, especially if the topics are of different types.
In this case, my preferred approach is a popup window that opens when you click on a link and lists the available resources. This is the default behavior in SPFE. If you are using a soft linking approach, however, in which the author marks up the affinity rather than the link, you can do just about anything with them.
The key thing you want to avoid here is burdening the author with trying to find and link to all the relevant topics themselves. That is way too much overhead, and produces results that are way too irregular.
I would be interesting to discuss how the topicmap standard related to affinities and linking. Topicmap is a powerful ISO-standard to make a map of subjects, ideas, topic or whatever we call it, that a searcher would be interested in knowing more about.
In a topicmap, you start by declaring “topics” (which is NOT the same thing as a DITA topic). I see a topic here as what Marks call affinity, for example a specific user task, a software function etc. You can then relate information sources to a topic by declaring a number of “topic occurrences”. This means that a user clicking on a link in a page, would first see the topics associated with the link and then be able to browse the topic occurrences (=other EPPOs).
Now, topicmap is to me very powerful as it allows you to declare types of topics (thus categorize topics, like using facets to classify objects). You can also declare types of occurrences (similar to DITA topic types). But, topicmap is even more powerful (complex?), since you can declare associations between topics and which role a topic has in an association. The association allows you to say that the “Installing Gizmos” topic is related to a “Using Gizmos” topic. Thus, a user that clicks on a link will not only be able to browse all occurrences that are declared for the topic, but also the related topics. At last, you can declare types of associations and types of roles (passive, active etc). When you have created a topicmap you can visualize it as done here: http://www.ontopia.net/page.jsp?id=vizigator. Excosoft is looking into how the “best-of” topicmaps can be incorporated in a faceted navigation portal for technical communication.
I would be interested in hearing how SPFE and affinities relates to topicmaps. Are the same solutions possible and if so, why not use topicmaps? We have concluded that the content creation process must start by first deploying the metadata scheme, whether we call it the matrix or a set of subject affinities. But when creating good EPPOs; do you first investigate the user tasks and then build a subject affinity network (not a matrix!) and then you write the EPPOs or in what order do you do it?
Jonatan, that is a very good point. Topic maps are indeed about mapping the subject affinities of information objects. In fact, given how overloaded the word “topic” has become (it used to be a synonym for “subject” and has become a synonym for “article”), their purpose might be much clearer is they were renamed subject-affinity maps.
SPFE builds relationships and links bottom-up, the same way a relational database or a linker/loader does, so it does not use any kind of written map as an input to the build process. On the other hand, it does build what is called a link-catalog from the indexes of all the topics, which is then used to create links during the build. That is half-way to being a topic-map. It would be easy enough, therefore, to generate a topic map of the information set as part of the build process.
One of the nice things about topic maps is they have a Web-like structure, so they can conform to the irregularities of the world.
When I propose that we begin with metadata, however, I mean something slightly different (though closely related). I mean that we should begin with strong subject-specific topic types. (A bottom-up approach requires strong topic typing.) That necessarily involves the management of defined namespaces.
The occurrence of values in these namespaces across different topic types then forms the prototype of a web of topics, but without precluding irregular relationships.
I’m personally a little reluctant to use the word taxonomy for these managed namespaces, because taxonomy to me implies not only a managed list of names, but a set of rules for naming things. But nonetheless, I think we are talking about the substantially the same thing. The differences lie in the difference between a top-down and bottom-up approach.
A couple of notes. When users search from Google and land on a help page, they bypass any faceted search opportunities, as they arrive directly at the page content level. In this case, to incorporate browsing mechanisms into search, you’d need to create the links at the page level rather than relying on facets in your search sidebar.
Also, check out Fluid Topics. It’s a pretty interesting platform. It’s not an authoring tool. It’s a web publishing mechanism for DITA or for other structured XML content.
Fluid Topics is made by a French search company (Antidot), which has been around for 15 years. Fluid Topics is a new product.
With Fluid topics, you can incorporate facets based on what you tag as “valuable” in your topics. In search results, if a topic appears in two different maps/navigations, you see both navigation links in the result.
Also, little topics get pulled together dynamically into one view (refreshed via ajax) as you scroll, which fixes the little DITA topics problem.
Also, you can pull the whole content into an existing website via javascript snippets, so you aren’t trapped into a tripane help look.
It costs about $800 a month or so depending on features (for 5,000 topics, I think). I think it might be a great fit for your SPFE architecture. The vendor guy at UA Europe said it wasn’t restricted to DITA but could learn how to process other markup.
Tom, I agree that we have to start thinking about navigation bottom up rather than top down.
I don’t see how Fluid Topics does that though. It seems to destroy the idea of a page altogether, so it’s tough to know what Google would index. As a way to put book shaped help on the Web, it has some interesting features, but I’m not interested in putting book shaped things on the Web, because I don’t think they belong there.
I suppose if one looked at Fluid Topics as a web-based e-reader rather than a help system, it might make more sense. But I’m overall a little puzzled about what the appeal is supposed to be.
Finally, mostly unrelated, but your site loading speed time is awesome. Your site loads in about 2 seconds, whereas mine takes 6ish seconds. Site loading speed is a factor in Google’s pagerank algorithm. (Part of my problem is that I have so many little randomly rearranging ads that slow the speed, as well as other fluff that I need to try to trim.) Anyway, I just thought I’d commend you on it.
Thanks, but it is purely the product of indolence, not design. I guess there are so few features, and so few graphics, that it improves load time, but to tell the truth, I never even thought about it.
What I would really like is to see more bottom-up organizational and navigational features in WordPress.