Skip to content

Documentation page structure - familliar patterns #186

@cyberschnaps

Description

@cyberschnaps

Issue description
Not all documentation pages have the same basic structure for subnavigation.

Why does it matter?
It impacts usability. It's a quick-win with a strong impact. It is a well know UX fact that familiar design patterns help improve discoverability, usability and overall navigation (Hicks, Jakobs, Law of Common Region, Law of Uniform Connectedness).

Context
The existing recurrent patterns we have in the documentation now are the following:

  • Understand the Basics
  • Configuration
  • Examples

Sources: Settings,

However some pages are mixing other elements at the same level of subnavigation, for example the Components page has:

  • Understand the Basics
  • How to find it?
  • Manage components
  • Actions

Other discrepancies include: Participatory processes, Conferences, Comments, and many more...

Proposal
Create a unified structure for subnavigation which is always applied. All other sections should become sub-sections. Example:

  • Understand the Basics (works fine)
    • How to find it
    • perhaps something else (this section should be kept short)
  • Configuration (or Options? which has a more permissive meaning)
    • Actions
    • Manage X
    • Create Y
  • Examples (works fine)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions