The last scroll position of each book should be saved and automatically restored. The book should never open at page 1 unless that's where the user left it.

Things to think about:

• How will changing screen sizes affect this? In a maximized window on a laptop, three songs are shown side-by-side. Which of these is the "current" one?
• Scroll position is intrinsically linked with the current search term. These will need to be restored together.
• If the scroll position is over song 123 and the user changes the search to one that includes this song (such as by clicking a link), should the page scroll to the top of the page, or should it stay in place? Since searches are effectively instant, there needs to be some feedback that the search was completed. Right now the "# of results" message is only shown at the top of the page.

There needs to be a way to scroll through a listing of each song in a hymnal. The hymnal XML data format already supports index data, including index names ("Index of Tunes", etc.), so this is purely a UI consideration. How will the index be displayed? There is already an indices menu on the document page that lists each index, but what happens when a menu item is tapped is still to be determined.

What is an Index?

An index is a listing of entries grouped by a particular piece of information. Different indices have different grouping. Within a group, each entry is also sorted, either alphabetically or otherwise. For hymnals specifically, there are quite a few indexes that could be available:

• Grouped alphabetically by title/first line, with alphabetical sorting
• Grouped by tune, with # sorting
• Grouped by author, with # sorting
• Grouped by translator, with # sorting
• Grouped by topic, with # sorting
• Grouped by day, with # sorting

Note that some indexes have the same entry in multiple groups, or with some entries not present at all.

Alternative options

Perhaps it would be simpler to add a "Listing" view that has controls for grouping and sorting that the user can control directly. But there's really no reason to do this because it's rare that someone would want to change the sorting.

Hymnals are very long documents that are frequently navigated to some arbitrary location. As a result, there needs to be a way to quickly scroll through the document. On desktop, this is easy with native draggable scrollbars, but most mobile browsers don't have these (Samsung Internet is a notable exception). There are reasonably-performant JavaScript libraries like react-scrollbars-custom that might be a good solution.

Adobe Reader for Android has a draggable nub scrollbar on the side of the screen that also shows the current page number, which seems like a good design. As long as it doesn't obscure the content like Adobe Reader does, I think that's the design I should aim for.