UI Design: Global page header for title, navigation, tabs, and controls

[alexhb1]

This is meant as a piece of follow-up work to PR #831 which introduces a new sidebar and full page design to the Grimmory UI. While the global topbar is intentionally removed from the main rework, there is merit in creating a global header component for all pages to follow, with common design for the below elements:

• Common page title design, as well as a small pill design for page-specific info.
• Unified navigation options, including breadcrumb and navigation back for sub-pages
• Unified tab switching design for in-page tabs
• A clear set of page-level action buttons with consistent hierarchy.

The result should be a coherent set of basics for every page in Grimmory, while also improving mobile responsiveness by creating a single optimised header UI that all pages get automatically instead of implementing manual and slightly different mobile changes for each page.

Screenshots below based on WIP build for visual reference, not final

---

Page title and dynamic info

• Ideally, every top level page should have a large bold title text (Library, Shelf, Dashboard, Settings etc). Dynamic info in a small pill alongside this.
• For subpages (book detail, author detail), the page itself already shows the title, so the header doesn't repeat it. The title space is used for a smaller navigation row instead.
• Extra info pill: Small primary color pill alongside the title, showing dynamic content. Used on browser pages (books, series, authors) for things like item counts, current filter and sort, or whether a search is applied.

Title should be specified by the page, either static pages automatically via nav-catalog which already exists, or for dynamic pages (Book, author detail) by a small service.

Example - Book browser page with main title and page-specific context in the pill

---

In-page tabs

• For pages with sub-navigation (Author detail, book detail, metadata manager), place tabs directly below the title row as part of the header.
• A single tab design used everywhere, replacing the ad-hoc tab layouts used on different pages.
• Tabs should be page owned but rendered through the global header to keep consistency and accessibility, as well as manage mobile responsiveness once and all pages benefit.
• Default placement is a second row beneath the title row, left-aligned. On wide desktops where there's blank space between the title and right-side actions, the tabs can sit centered in the main row. They wrap back down to the left-aligned second row when width is constrained. If this looks weird, we can always just keep the permanent second-row for tabbed pages.

Example centered tabs in main row

Example tabs below the title / nav content

---

Navigation and breadcrumb

For subpages, the header's big title is dropped and the page itself shows the title. The title space becomes a smaller navigation row with two pieces:

• Up-level back: a single back button returning to the previous page. Useful when arriving via deep link, or after going from one page to another (book to similar book, author to book, etc). No browser-style back/forward, just up to the previous level.
• Breadcrumb: shows the path the user actually took. E.g. go to a book from a shelf and the breadcrumb reads "Shelf X / Book Y". If via an author page, "Author X / Book Y". Books in Grimmory don't have a single fixed parent (they can live in multiple shelves and libraries) so this makes sense and helps the most with navigation.

For chained navigation (book to similar book to similar book), the breadcrumb keeps the original entry point and the current page rather than just adding everything. To stop it getting totally off track, I guess a rough rule is that it can extend one level deep when you keep navigating in the same direction, but resets if you go off-track. TBD.

Example breadcrumb on book details page instead of a main title

---

Page level actions

The right side of the header should be reserved for page-level actions, following a clear hierarchy across each page:

1. Primary action: One per page, the headline thing you'd do on this page. "Upload book", "Edit metadata" etc.
2. Secondary actions: Icon-only supporting actions with tooltips. Can be multiple.
3. Overflow: Everything else, single overflow button opening a menu

Example actions in the book details view

Enforcing the hierarchy should give the app a unified model for basic actions on each page, and remove some of the inconsistencies across pages in the current UI. This should make it easy to add mobile responsiveness for every page that uses these controls.

[zachyale]

Love the breadcrumb, and much prefer this paradigm where the sidebar maximize/minimize button is still within the sidebar, & not brought out to the page header.

As an aside- in experimenting with how we can improve the audiobook tools/featureset, I've been looking into the best way to surface audiobook specific tools and editing flows. The breadcrumbs would really help to solidify the navigation context for users (i.e., "<- A Higher Loyalty > Edit Metadata", or "Edit Chapters", etc). I know in the initial ironworks prototype you first posted a month ago, the search metadata/edit metadata were pulled out from book detail view tabs into their own views- is that still the way you're thinking about splitting up the book detail view?

[alexhb1]

Question: Any reason we need to keep the hybrid book details page? Right now it is technically a dialog embedded as a page, you can change to open as a dialog if you like. It's pretty messy to manage everything as-is, making it a normal page would streamline a lot for this.

[zachyale]

What do you mean specifically by "hybrid page"?

[zachyale]

While we can leave it to the PR, if we move actions into their own buttons or dropdowns, do we really also need the segmented control/tab bar at the top still?

[alexhb1]

This is the setting for book details fyi

On the tabs, we can probably make them a proper page yeah. Edit tools at the top like a toolbar. The breadcrumb will help with that.

[zachyale]

Wow, I never noticed that option or had played with it. This is nuts, I think we can definitely kill the option and move details to pages.

Edit: it's broken anyways- on iPad if you open a book detail view as a dialog/modal, and then open a reader, the modal stays on top of the reader

[alexhb1]

Issue here: #1109