The problems, such as they are, arise in the fact that developers often want to return navigation in a single API call, and editors want to be able to see their information architecture reflected in their content hierarchies within Contentful. If we treat website navigation solely as "… a visual representation of an information architecture, to help users navigate around the website." (Wikipedia) that’ll go some way to helping us think about approaches to navigation that will hopefully not annoy your editors (too much).
Although navigation acts as a representation of the IA of a website it doesn’t ultimately need to be this (although that is one technique). It could be simply represented as a set of labels, and hyperlinks. More complex navigation systems may also require these label/hyperlink combinations to have a representation of hierarchy (maybe a parent or a child) and then a navigation element could be accessed from multiple places and be repeated. Pages may exist and not want to be listed on the navigation, a separate section of the website might need its own navigation. The mobile version might have its own navigation, different languages might want their own types of navigation. Some navigation could have a sub menu, some might not…
Let’s just say it could get complicated. If we work out how we could think about approaching modeling navigation in some generic ways most of the above scenarios should be covered, and we get a content model that is a joy to use by both developers and editors.
As with any content modelling exercise, starting with a full understanding of your content and working from there goes a long way to being efficient in your decision making process. Working on paper, with post its or on a whiteboard first can also help save time in the long run, as your mental model can change as new information is gathered. I would also recommend that the modelling exercise is done cross functionally with a team of designers, developers and editors (at the very least).
It is recommended that, if you haven’t already, you read up on Topics and Assemblies first.
This model is great if you content is true pure topical content that is then parsed/rendered using a different set of things. Ultimately if the raw ‘things’ in your content are related to each other - and that is how you want this information to be represented, then this pattern may work for you.
Exact implementations vary but the process is the same:
When generating navigation in this way the relationship can be pulled at the same time as the main body of content. Reference fields with a linkType to an Entry will then create your relationships, and your application can parse this easily.
Doing this up front to generate the navigation can be costly, so this approach is perhaps best suited to websites that are either static or have some server side component.
If your content is designed to be specifically displayed on a website, and the page assembly is the core way users access the content (via a uri for example) then assembly relationships may work best for you.
In this way if your assemblies have children that are topics they can also have children that define the relationships - but it is important to note that the pages have relationships, not the topics themselves (although this could be combined with other relationships in the topics - for example a looser relationship like ‘related to’)
The implementation process is the same as topical relationships, but will possibly follow a more strict sitemap structure.
One way of thinking about navigation is to flip the above approaches on their head and create a content type specifically to hold navigation information, and structure pages or topics as references within this content type.
This allows for multiple navigation elements which can be especially useful if your website or application has different menus. This can be set up as a flexible or inflexible hierarchy depending on the fields and validation you include in your navigation content type.
These can then be used as sub-assemblies within your content model and re-used or shown in different parts if your page.
An extension to the above approach is to make use of another content type, commonly called a routing object, this can hold information about the location of the page (url part/screen depth etc.) and then can be attached either to the page assembly or topic as well as used as the leaf node in place of the page or topic itself. This approach is really useful for handling navigation separately
Ultimately if you want your navigation to be better, thinking about how the relationships between your content areas should be defined and at which level you’ll be better off. Contentful supports such a flexible content model that it can be daunting when approaching something like navigation that has traditionally been dictated by a particular traditional CMS or just managed in markup.
By forcing you to understand your content and its relationships will ultimately help you make a better product, or at least you’ll be communicating your information architecture more effectively through your application, because you’ve managed to model it in a sensible way.