Tag Archives: Index

Indexing in an online world

indexing

When you think of an index, what do you see? Maybe you think of those tabulated sections at the back of printed documents. In terms of online help files you may think of that Index tab requiring the user to do pretty much the same as a search. In this modern online world, it is no surprise that increasingly the poor old index is ignored by Technical Communicators. Or is it being ignored at all?

Indexing an Adobe RoboHelp topic the easy way

indexing

I know that in some quarters indexing is going out of fashion, but in some it is still considered a vital element of any content. For large text based output (yes this does still exist) an index can be an invaluable method of allowing users to choose the best place to get the required information.

Are TOCs required in a “Search Centric” World?

Let me put my cards on the table here. I am a man of a certain age with many years experience in using and producing help files. I hark back fondly to the days when a Table of Contents was the only means of navigating. All my documentation has a Table of Contents and I insisted that a specific set of rules be included in our Style Guide on the subject. All of this aside, time marches ever onwards and I believe it is right for you to have your say on the matter.

This post was inspired by a twitter poll run by RJ Jacquez, Adobe’s Senior Product Evangelist, which asked whether we see a TOC as being a required element of a help file. There is no doubt that younger, more technical users interact with help files in a different way than I did when I was their age. Technology has advanced and searching offers many user benefits that simply were not available years ago. Demands on our time mean we want a quick and easy method of finding what we want. But to answer the question of whether a TOC is required, we need to address the following questions:

  1. Is a search facility the only method a user needs to find content?
  2. Does a search give the user 100% of the required information?
  3. If it doesn’t, how do they find the rest?

The answer to the first question is, “It depends.” The mantra of any technical communicator is, “Know your audience.” If they don’t want a TOC, never use one and are paying for you to deliver the end product, you pretty much have your answer right there. However it should also be part of our role to educate our users where required. Part of that is should be extolling the advantages of the TOC (and Index for that matter) and how it can be used. This leads me nicely onto the second question.

So you want to find out how to do something, you open the search tab and type in a question. As if by magic, a long list of results is returned. Problem solved! Or is it? Which result do you look at? Does the result at the top of the list provide the required information? Do you have sufficient information visible to make a judgment? All of these questions highlight everything that is wrong with search functionality. By its nature it is subjective. Each search tool’s algorithm works in a particular way and there is nothing you can do to change it. Perhaps you can include keywords in your content that will be picked up, but that’s about it. It is just the nature of the beast that you have little control over what it returns.

So you have a list of 10 topics to choose from with only a limited amount of information available to enable you to make the right decision. You click a link and read the content. As luck would have it, it provides you with the answer and away you go. Trouble is, five minutes later you get stuck again further down the process and have to repeat the process all over again. If only there was a means of identifying where you were inside the help file’s structure. Then you could look inside that part of it and see if there was something more likely to meet your needs. What? There’s no TOC? Expletives deleted!

Is a Help File Index on life support?

I have to admit to asking this question with my tongue placed squarely in cheek. I have always been someone who has ensured that people know of the value of an index and have taught others about how to index effectively. I have fought to ensure that sufficient time is allowed as part of a project to index properly rather than just an hour or so at the end. However despite all of this, I can’t help feeling that the importance of an index is subsiding. If you think I am overreacting, consider the following.

Over the last few weeks, I have been helping a Technical Writer who had been struggling to update a legacy project that had been upgraded from RoboHelp X5 to 8. As they were themselves new to RoboHelp there were loads of questions relating to the product’s use. We have got to a state where things are almost ready to publish when the subject of indexing emerged. It was clear that they were more than a little confused by the functionality offered to index topics in RoboHelp 8. On the face of it the RoboHelp interface for indexing topics has not changed very much from the early versions. You add keywords and sub-keywords, assign these to topics and these appear as if by magic in the Index tab of your help file. Even the Smart Index Wizard hasn’t changed and can be used to index if you really want to suffer a nervous breakdown.

A major change came in RoboHelp 8 with index keywords being included in the search database that is built when the help is generated. What this means is that if a topic has an index keyword of “RoboColum(n)” but there is no mention of “RoboColum(n)” anywhere in the topic text or title, that topic is returned in the list of results if the search string is “RoboColum(n)”. To allow this new functionality to be extended, you can now add keywords to a topic, which are therefore searchable, yet are not themselves displayed in the Index. What gives? Take a look at your Topic Properties. As well as the familiar Index tab, take a harder look at the General tab and the “Keyword” field. This is the field that allows you to specify keywords separated by commas that users can search for to find the topic.

If this doesn’t convince you of the decline in importance of an index, consider the advent of Adobe AirHelp. It celebrated its second birthday this week and has caught the imagination of many. AirHelp is an output option in RoboHelp 8 and it offers many advantages compared to other outputs, even when compared to WebHelp and FlashHelp. The Adobe RoboHelp help file is just one example of this output type, albeit a tailored one, but if you have looked at it you will notice there isn’t an index in sight. Nada! Nothing! There is a search field but with the ability of the search to “find” index keywords, it can be argued that it really isn’t required.

Of course whether an index is available in your help file is entirely down to you, but the advent of a younger, more googlised user base has seen users of an index decline. The index may not be dead yet, but I can’t help feeling that it will continue to decline to the point where more and more Technical Writers will stop creating them. It will be a sad, yet inevitable, moment if that does happen.

Indexing. The line in the sand.

Call me old fashioned but I still believe a good, well structured index is more useful than any search facility in a help file. The search algorithms employed just don’t quite cut it for me which is why I really do believe that taking the time to index is time well worth spending. Of course indexing is not a quick and easy fix, although I’ve seen many an index that indicates there are people out there who think it is!

Compiling an index requires a particular type of methodology. If ever there was a time when you had to get inside a user’s mind, this is it. You have to think of why the user may want to see this topic and what keywords are they likely to search on to do so. Will they use an acronym or an abbreviation? What does the topic contain? Does it have ancillary information that a user may require? If so it needs indexing.

It is natural for Documentation Managers to balk at the time it takes to index a help file properly. This is especially true when the expectation is that the help has a search facility. Why should you spend a week indexing a help file when you have an adequate search tool that allows users to find what they want with only minimal effort from the Technical Author.

This short sighted view overlooks two vital points. Firstly, many users still prefer using the index for finding help. The Google generation may be alive and well but it hasn’t quite taken over yet. An index is quick and easy to use and is more likely to provide accurate results if the author has taken the time to index correctly. The second point is that various forums are awash with users having questions and/or problems with the database of search results provided by their HAT. So much so, that they often use an alternative. My friend Peter Grainge has an article on his website that shows how to employ ZoomSearch as part of your WebHelp output.

You could employ the sneaky technique of indexing and then renaming the index tab to “Search”. The users think they are searching when in fact you’ve duped them to use an index. I’ve heard of this approach being used but it should only be used as a last resort. To me indexing is an art form but one which is absolutely required. Any lines in the sand of resources must be drawn after any full and proper indexing has been resourced.