(this page was created automatically. In case of formatting issues, please visit the official Wiki Page)
Local Navigation
Overview
Local Navigation helps users move within a specific product area or workflow. It complements Global Navigation by enabling navigation that is context-specific, task-oriented, and adaptive to the current dashboard or process step. While Global Navigation connects users to system-level destinations and cross-product areas, Local Navigation supports the “work inside the page”—helping users understand where they are in a flow, jump between related sections, and move forward or backward without losing context.
Local Navigation is intentionally dynamic and flexible. It does not need to exist everywhere in Edge.One. Simple applications might not require it at all. Local Navigation is introduced as soon as dashboards develop dependencies between each other—such as favorites, nodes, and multi-dashboard processes. Because it is limited to the current dashboard context, Local Navigation can vary between dashboards and should reflect the structure and needs of that area rather than forcing a one-size-fits-all approach.
Anatomy
Local Navigation is composed of a set of reusable navigation surfaces that appear within a dashboard to help users move through related content and workflows. These elements are chosen based on the complexity of the application area: some dashboards only need lightweight navigation (for example, breadcrumbs or in-content links), while others benefit from a persistent structure such as a Navigation Boardlet. The following sections describe the key components and how they work together to support both vertical drilldowns and horizontal, step-based flows.
Navigation Boardlet (link to page)
The Navigation Boardlet is an expandable navigation element placed on the far left of the dashboard, spanning from top to bottom of the page. It provides a collection of tools and links to different aspects of the current application area, usually presented as a list or a tree list. Navigation items are commonly organized into groups to improve scanning and to align with the information architecture.
The boardlet can include dynamic elements that update to reflect the current stage of the application or the user’s context For example, counters to the right of links can indicate the number of items in a library behind that link. By combining hierarchical structures with direct links, the Navigation Boardlet supports both horizontal navigation (moving between peer areas or steps) and vertical navigation (drilling down into deeper levels of detail).
Click here for more information on the Navigation Boardlet.
Breadcrumbs
Breadcrumbs show users their current location relative to the information architecture. They enable users to quickly move up to a parent level or return to a previous step. Breadcrumbs are always located in the left part of the header. Breadcrumbs support vertical navigation inside drilldowns and adjust based on the user’s current position in the structure.
All page items in the breadcrumb component are interactive and link to the corresponding pages. The go-back icon moves back one step at a time within the page structure.
Navigation Actions inside the Content
Navigation actions are navigation elements placed inside the dashboard content. They enable users to move through workflows and drilldowns directly from where they are working, rather than relying only on side navigation structures.
Common placements include:
- Buttons in toolbars
- Links and buttons within dashboard content
- Actions inside tables
- Actions from dialogs
Tables
Table navigation is commonly provided as part of row actions, usually in the last column. It typically routes users to a drilldown page (for example, a details view), representing vertical navigation to the next layer in the breadcrumb structure. The destination screen should provide a clear “back” option to return to the prior context.
Buttons and Links
Navigation can happen through buttons or links placed within the dashboard content, often to support process flows. They are commonly used for horizontal navigation through a sequence of steps. Typical examples include “Next” and “Back.” These actions usually appear in toolbars, footer bars, or at the bottom of the content and should be used sparingly to avoid clutter and conflicting navigation paths.
For more information, please go to the Wizard pattern
Dialogs
Dialog navigation is usually implemented through footer bar actions. It typically includes two directions:
- An option to return to the current page (“Back” or cancel/close).
- An option to move forward by initiating a process or confirming an action (for example, accept, submit, or continue), which often leads to a new page.
Depending on the action performed, dialog-based navigation can represent vertical navigation (to a deeper level) or horizontal navigation (to the next step in a flow).
Best Practices
Balance context-adaptivity and consistency
Local Navigation should reflect the user’s current dashboard, task, and information architecture. Avoid reusing navigation structures that don’t match the local workflow, and keep the available options relevant to what users can do from this area.
While Local Navigation can vary between dashboards, patterns should remain consistent within the same application area. Use the same placement, interaction model, and naming conventions so users can predict how navigation works.
Keep it simple
Use Local Navigation sparingly and avoid duplicating Global Navigation. If users need to jump between dashboards or products, that belongs in Global Navigation—not local structures.
Prefer clear groupings over long flat lists, and avoid deep trees. If a structure becomes hard to scan, add grouping, shorten labels, or introduce search and shortcuts instead of adding more nesting.
The right surface for the job
Use a Navigation Boardlet for persistent cross-section navigation within an area. Use breadcrumbs primarily for orientation and moving up a hierarchy. Use in-content navigation actions for step-based flows or drilldowns where users need to act and then move forward.
Navigation inside processes
Do not navigate users directly into the middle of a process or conditional content. Local navigation should route to process entry points or overviews. Step-to-step movement belongs inside the process UI (for example, Next/Back actions).
Drilldown destinations should include a reliable “Back” option or a clear breadcrumb path. Dialog-based navigation should always include an explicit way to return to the current page without progressing.
Language
Use user-facing language, keep titles concise, and match labels with page titles. Avoid internal jargon, and ensure similar destinations have distinguishable names.