Monday, October 21, 2013

Herding Tigers: Changing Our Reliance on Inline Links

Mysti Berry asked "What's wrong with putting a link on it?" Were talking about links put in by hand. Well, if you have a link from topic A and you link to topic B, what happens if you delete topic A?

Links slow readability ever so slightly and they slightly decrease comprehension and recall. Inline links in our research found inline links were clicked 0-8% of the time. (But more research is needed.) If you're using Arbortext, the Resource Manager can make it take minutes to create one link. Refactoring content that contains links is a nightmare. So we're spending time and money on resources that few people use and that slow down those who do.

If we stop with inline links, we might miss the content architecture that works better for our customers.

We found that content with embedded links caused refactoring to balloon from 4 hours to 3 days.

As things change, we don't tend to inspect the link chains that we create. In many cases, we end up with link chains.

Links can damage the scent of information. Often, once you click on a link, you don't go back.

If you couldn't use links, you might create more self-contained topics.

As a part of a re-architecture project, removed inline links that crossed "bundle boundaries," which was about 4300 links, almost 50%, across 4000 topics.  Had to find links that pointed outside the ditamap. For each link, had to decide if it was necessary. If a cross reference (or XREF) is necessary, why isn't the content that it links to?

One solution: Get users back to the UI. They don't want to be in the help anyway. If you can, get them back to work.

Another: use conrefs instead of links. (This is DITA only, of course.)

Or even fix the topic. Can be hard to articulate. Writers would fix on a case-by-case basis, and not always time when lots of topics. It depends on what's wrong. Is the user goal unclear? Is it "overstuffed?"

It's hard to let go of links. It's hard to see that something good for the few affects (negatively) the needs of the many. "Minimalism" can be mis-interpreted, trying to make small topics. But think about making topics solve user goals.

Think COPE (create once, publish everywhere). You can't COPE with entangled content.

have to not blame the writers. They are fierce customer advocates. But the metrics show differently. Make your initiatives backed by data.

It also requires an investment in project management. Analyze the problems before you begin. If you can, work on a small chunk of content at a time. Fix it and publish it and show everyone, including writers, where you want to go.

Don't go overboard on reuse. Reuse before the sentence level can cause problems.

No comments:

Post a Comment