Untangling the Web navigation conundrum

There’s been an interesting series of posts recently by Tom Johnson on enabling users to navigate through content in lots of ways (instead of just providing them with a Table of Contents and a search box).

ravelry.com faceted searchIt’s the type of approach used by sites such as Ravelry.com. Ravelry is a popular social networking site, with over 3 million users, for people who like to knit. It has sophisticated faceted navigation and search capabilities that mean users can search for the ideal knitting project in lots of different way.

You can search by type of pattern: cardigan, socks, dress, and so on. You can also search by type of yarn. For example, if you have 4 metres of two ply lace, it will show you the patterns which require that type and length of yarn. In fact, you can search by lots of different factors, such as the type of knitting needles you have, the level of difficulty and the users’ ratings of each patterns.

This approach works well if you have content that follows a predictable structure: if your content could be entered by filling in fields in a form or a database.

What do you do if your content follows a more unpredictable format?

The challenges lie with content that follows a less predictable structure, such as reports, user guides, proposals, blog posts, and so on. You often don’t not know what you’re going to include until you start writing. You might also want to include hyperlinks to related content at unpredictable points in the text.

Structured writing

Within the technical writing community, many recommend using semantic, structured writing standards to deal with this issue. Your text looks like roughly like this:

[recipe][dish]Fish and Chips[/dish][/recipe]

Your text is still categorised and structured, but you have more flexibility over how it is categorised and structured. For example, DITA has three main simple types of content (Task, Concept and Reference), to which you can add your own specialist types and taxonomies.

It’s different way of writing to what people are used to, and many find it hard to adapt. You’ve also got the issue of all the existing content your organisation has. You’d need some or all of your existing content modified to fit your structured format to make it navigable in this way.

Adding semantic information at page level

As an alternative, what many organisations do is leave the sentences and paragraphs in an unstructured, non-semantic, form and add semantic data at the page level (in the technical writing world, we also call a page a “topic”). You can use metadata, through the labels and tagging features in tools such as WordPress and Drupal to add information about each page.

In Tom Johnson’s post Moving Beyond the TOC in Organizing Help Content, he includes this graphic to illustrate how you can the use metadata to create dynamic, filtered and faceted navigation links:
metadata example

The advantage of this approach is writers can simply write – they have a familiar authoring environment to work in, and they can leave the tagging and metadata to later (or to someone else).

The downside is, it’s difficult to filter or navigate by types of information contained within the page. For example, if some of your pages contain warnings or legal disclaimers within the body of text, it might be useful to create a list of all the warnings and disclaimers. You can add metadata to the page saying it contains warning information, but that will only direct you to the page and not to the warning itself.

A workaround: Embedding pages within pages

One way to get around this issue we have implemented for clients, is to embed a page (or a topic) within another page. If your warning is contained in a page (and that page contains metadata identifying it as a warning) that is then embedded into another page, you can then create the lists and filters of the warnings we mentioned above.

Embedded warning example

You probably don’t want these individual warning topics appearing in your main table of contents, so you should locate them in a dedicated folder that’s excluded from your Table of Contents.

Summary

Adding semantic information to your content enables you to provide lots of different ways for your users to filter and navigate the information. However, you need to decide where this semantic structuring occurs. Finding the right balance between having a friendly authoring environment and establishing a usable structure is a challenge many organisations will have to adress in the future.

2 Comments

Scot Marvin

Excellent post, Ellis. Thank you. I think that providing semantic information in addition to a TOC is only adding greater help for folks to find information. I think replacing TOCs without a better way to navigate is a mistake. You still have to meet people where they are, and some still prefer a TOC with a logic flow–even if that flow isn’t sequential.

In my personal (hence, limited) experience, semantic information is wonderful for retail items. I love it in Amazon, L.L. Bean, etc. However it’s problematic for nebulous conceptual things like configuring DRBD in Linux. I have no data to back this up. Just a hunch that it would prove difficult–or maybe I’m using such configuration information in a sequential manner that benefits from a structured presentation listed in a TOC.

Anyway: thanks for adding to the conversation.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.