Concept markers vs. Index markers

[MarylynGK]

This is a best practices question. Why would I use both?

It seems that since I need an index, and I can use the Search Index help control to automatically generate my list of related topics where needed, then index markers are all I need. I'm tempted to clean up my project by deleting all my concept markers. But before I do, I'd like some advice.

And a related question: how do having index and/or concept markers in a topic affect the topic's ranking in a user search?

[forfear]

Concept markers help you group and set up See Also relationships between different topics

About Widgets
Adding New Widgets
Deleting Widgets

This is used only in CHM Help, Webhelp formats with the See Also controls.
You cannot set up hierarchical relationships with Concepts. You simply use keywords to group them together.

Index markers, however, helps people find content, based on keywords you use, or keywords you think they might use.
You can define index markers according to a hierarchy aka taxonomy.

X
See:widgets

widgets
about
adding
deleting

When indexing, you are improving the findability of content for print, and online help formats.

[MarylynGK]

Thanks, forfear, for trying to answer my questions, but my original two questions remain. Anyone else have some insights to share?

Marylyn

[KevinDAmery]

Forfear is right. Indexes and concept links are two different things that get used for different purposes, so having both in your help system is perfectly valid.

- The Index provides a place where users can look up all of the tools, concepts, terms, etc. that are included in the documents. The idea is it shows everything that the writers think is important in the document and tells readers where each one can be found.

- Concept links allow you to assign a topic to being related to a particular concept, and to add link boxes to topics that automatically provide links to all other topics that are also related to that concept. For example, if you decide that a topic is related to Archiving Data, the Related Links box would provide links to all of the other topics that are related to Archiving Data. The idea is this gives readers a quick way to jump to other topics that might help them with the specific concept being dealt with in the topic.

So clearly, the reader is using these in a completely different way, even though you may have the same words (Archiving Data) in both the index keywords and the concept keywords.

As far as search rankings go, that I'm not sure.

[MarylynGK]

I get the difference in the technicality, but not in practicality. As I said in my original post, I can use the Search Index help control to generate a list of related topics based on the index markers, so I don't need to create Concept markers to get that functionality. I can also define the style of the Search Index help control to have the label See Also, or Related Topics, or anything else I want to call it. And the hierarchy in an index is not a problem either.

Also, a colleague did a test and learned that Concept Markers are not read by the search engine, but Index Markers are.

So as a best practice, I'm eliminating Concept Markers from my project and keeping it streamlined. If I choose to add them in the future, it will be very sparingly for a restricted purpose.

Marylyn

[forfear]

I get the difference in the technicality, but not in practicality. As I said in my original post, I can use the Search Index help control to generate a list of related topics based on the index markers, so I don't need to create Concept markers to get that functionality. I can also define the style of the Search Index help control to have the label See Also, or Related Topics, or anything else I want to call it. And the hierarchy in an index is not a problem either.

Also, a colleague did a test and learned that Concept Markers are not read by the search engine, but Index Markers are.

So as a best practice, I'm eliminating Concept Markers from my project and keeping it streamlined. If I choose to add them in the future, it will be very sparingly for a restricted purpose.

Marylyn

So, do your index markers first.

If you have time, you could use Concept markers, for your Webhelp and HTML Help outputs.

Index markers are usually nice enough to have in professionally developed content.

[NorthEast]

I get the difference in the technicality, but not in practicality.

There may not be a difference in your particular project, if all the topics you want to group together also share exactly the same index markers. However, you wouldn't be able to group together topics that don't have the same index markers, you'd need to use concept markers to do that.

Also, another difference is that concept markers can be used in search filters, so you can limit your search results to those topics containing a particular marker (or markers). For an example, try a search in the knowledgebase (http://kb.madcapsoftware.com/). The list of MadCap applications in the 'Filters' list are linked to concept markers in the topics, so you can show only those topics related to a particular application.

[MarylynGK]

Thanks David. The explanation of how to use concept markers in a filter set is helpful.

[AudreyC]

I've been struggling with this question for a while - and here's what I've come up with:

I use concepts for lateral links and index words for "detailed" hierarchical links.

For instance, I have an Audio library in my project that contains a variety of objects (sounds, listeners, emitters). By applying the Audio concept to all of the topics in the audio library, I can then have a "see also" link to facilitate access between objects within the library.

The TOC provides a hierarchical approach, so I didn't need to just replicate that in the index. This led me to question exactly what I wanted my index to do! In the end, I use the index keywords to refine the hierarchical approach I've used in the TOC. Each "task" topic is indexed by Object type, and the Object type concept page is indexed by library. I also use index keywords to provide access to details that don't appear in the TOC but that people might be looking for. For example, in my Scrum handbook project, I have a page on metrics. There are two metrics described on that page: Velocity and Focus Factor. I don't want those to appear in the TOC, but I know that people may be looking for those specific terms, so I index those.