Chapter navigation: show place, progress and access
Ten recorded reading and listening apps show contents lists, chapter progress, duration and locks. Help readers jump without losing their place.
A contents list is not just an index of titles. It is a navigation surface with a memory: where the reader is, what they have already reached and what happens when they choose another chapter. Those states should remain distinct even when the list also contains page numbers, percentages, durations or locks.
Start with the current location and make a deliberate jump easy to understand. A reader opening Contents may want to check progress, revisit a passage or move to the next section. Do not assume that opening the list means abandoning the current position. Dismissing it should leave the book unchanged.
The ten recorded examples include books, serialized fiction and listening-oriented summaries. They show different navigation metadata and access states, not equivalent reading models. Use the comparisons to define your product’s contract rather than placing every possible badge on the same row.
Keep book progress separate from chapter position
Apple Books shows Page 6 of 128 above a contents list and highlights Preface. Storytel combines chapter and subheading entries with page numbers and a book percentage. These measures can complement each other, but a number needs a scope: position in the whole work is not progress through the selected chapter.
Label the meaning of progress instead of letting placement carry the entire explanation. A percentage beside the book title should not be mistaken for a completion score for the highlighted row. If pagination changes with text settings, preserve a stable reading location and treat the page number as a presentation of that location.
Do not equate the current chapter with completed reading. Opening a chapter can make it current immediately, while completion is a different event with its own definition. Use distinct states if both matter. The contents list should remain accurate after a person jumps backward, skips an introduction or opens a reference section without reading everything before it.


Support both rich and sparse contents
Fable separates Contents, Highlights and Notes and marks a selected location. Litres separates Contents, Bookmarks and Quotes, while the recorded list contains a single long chapter entry. A navigation surface needs to work for both a detailed hierarchy and a sparse work that offers very few formal sections.
Keep chapter navigation separate from personal material such as highlights. A reader should not need to search their notes to locate the next part of the book. Conversely, a highlight is not a chapter simply because it can navigate to a position. Preserve the difference in labels and accessible structure.
Let long titles wrap without hiding the identifying words or pushing position metadata out of alignment. With a single chapter, do not fill the page with invented subdivisions. Provide the genuine structure and a clear way back to reading. For a nested list, communicate hierarchy without making child titles so indented that they become unreadable on a narrow phone.


Explain chronological and reverse chapter order
MyFiction shows a long chapter list in descending order, with a visible sort control and locked entries. Wattpad shows numbered chapters with publication dates. Serial content can make the newest entry useful, while a person starting the work generally needs the beginning. One default order cannot silently serve both intentions.
Make the current ordering explicit and preserve it when returning to the list. Sorting by newest publication is different from reversing the story’s sequence if chapters can be revised or republished. If dates are shown, identify whether they represent original publication or another event when that distinction matters to the task.
Keep chapter identity stable when the author inserts or reorders material. A saved position should not jump to a different chapter merely because the list index changed. Support a direct route to the current location even in a large list. Otherwise a reader may spend more time reconstructing their place than choosing where to go next.


Do not make one badge explain every access state
AlphaNovel shows a progress value on Prologue and Locked labels on later chapters. Mobo distinguishes Downloaded entries, Free entries and locks. These are different dimensions: progress describes reading, download status describes local availability and a lock indicates an access restriction that still needs an explanation.
Avoid treating downloaded as synonymous with accessible, or free as synonymous with stored offline. A person can have access to a chapter that has not been downloaded. A retained local file may no longer be usable under a changed access state. Define those combinations and communicate the relevant consequence before the reader leaves the current chapter.
Do not infer the reason for a lock from its icon alone. It could relate to purchase, progression or another product rule. Name the actual rule in the surrounding flow and show the next step. If a chapter cannot open, preserve the existing position and provide a recoverable explanation instead of moving the reader into an empty destination.


Name listening duration and current playback separately
Everand displays durations beside chapter rows and highlights an active entry. Bookey lists chapter-length summaries and shows a current Chapter 2 of 5 context behind the list. Time-based metadata can help plan a listening session, but a small time value can also be mistaken for elapsed playback or a start timestamp.
Use a label or consistent context to establish what the number means. Chapter length, time remaining and a position inside the whole recording are not interchangeable. If playback speed changes the displayed estimate, explain that relationship where useful instead of presenting two unexplained durations for the same content.
Define what choosing a chapter does to playback. A reading-only jump and an audio jump can have different expectations. Where both exist, keep their positions coordinated according to the actual product model, and avoid unexpectedly starting sound merely because the person inspected the contents list. The static screens alone do not establish either app’s autoplay policy.


Use stable locations rather than list positions
Represent the work, chapter and location with stable identifiers. Presentation details such as a row index or rendered page number should not be the only source of truth for a saved position. Keep the current location separate from a temporary destination selected inside the contents panel until the navigation operation succeeds.
Resolve access and local availability before completing the jump. Preserve the prior position if loading fails, and retain enough context to retry the chosen chapter. When a long contents list loads incrementally, do not let new entries push the highlighted row to an unrelated place or reset an explicit ordering choice.
Decide whether a previous-location action belongs in the reader. A quick reference jump can benefit from returning to where the person was, but that history should not become a second unexplained progress system. Store the meaningful transition, label the return destination and test it across reopening, content updates and an unavailable chapter.
Ask readers to find and return, not just tap
Start partway through a work. Ask the tester to identify the current chapter, jump back to a named section and return to the earlier reading position. Include a long title, nested headings and a work with only one chapter. Observe whether the labels answer the task without an explanation from the moderator.
Repeat with reverse order, a newly published chapter, a locked destination and an offline state. Check that the reader does not lose a valid current position when the new destination fails. For listening products, include paused and playing states and verify what choosing another chapter does to sound and timing.
Evaluate incorrect jumps, lost positions and inability to return separately from contents opens. A high number of visits may reflect poor orientation rather than engagement. The desired outcome is that readers understand where they are and can move intentionally, not that they spend more time interacting with the navigation panel.
A chapter-navigation specification should answer these
Use these checks on a working build, not only on the polished reference state.
- Current location and completed reading are distinct states.
- Every page, percentage or time value has an understandable scope.
- Long, nested and single-entry contents remain usable.
- Chronological and reverse ordering have explicit labels and stable identity.
- Access, download and progress indicators do not substitute for one another.
- A failed destination preserves the prior reading position.
- Audio behavior and return navigation are verified in the working reader.
Questions and answers
Questions worth resolving before shipping
Should the selected chapter also be marked completed?
Not automatically. Current location indicates where the reader is, while completion needs a separate product definition. A jump backward or a brief reference visit should not rewrite both states as if they were identical.
Is newest-first ordering best for serialized fiction?
It serves one task but can obstruct another. Make the order explicit, provide access to the beginning and current chapter, and preserve stable identity when content is inserted or revised.
What should happen when a locked chapter is tapped?
Explain the actual access rule and next step while preserving the previous position. A lock alone does not establish whether the restriction concerns purchase, progression or another condition.
2,805 apps in the top charts.Ask them anything.
Use ScreensDesign Pro to inspect real chapter lists and their reading context before specifying progress, access and position recovery in your own app.