Tab support

[dstillman]

We could do this just in the PDF reader, but I think it will make more sense to mirror the desktop app:

• The library view is always the first tab
• The tab bar is hidden unless have at least one non-library tab open
• The library tab is fixed on the left, with scrollable tabs to the right of it
• The tab title for the library view is the selected collection
• The tab title for PDF tabs is based on metadata and configurable from the app settings
• We can remove the Back button in the PDF reader — you'd go back to the library tab by tapping it or by closing the tab
• Tabs (other than the library tab) can be dragged around
• Tab jumpback: if you open a tab and then close it in the same session without switching to another tab manually, selection jumps back to the opening tab, not the tab to the left of the current one as it would otherwise

We should also open web snapshots in tabs.

Down the line, both on iOS and desktop, you'd be able to open a note in a tab too, for a full-window editing experience, and probably multiple library views (e.g., open a collection in a tab).

Logically the tab bar is the parent of each view, so we should try putting it above the toolbars, as we do on macOS. My only concern is that if you miss and tap the status bar, you could accidentally trigger the scroll-to-top behavior and lose your place, but let's see whether that actually happens.

And then the other general concern is just encroaching on reading space. We'd obviously hide this when hiding the status bar and main toolbar in the PDF reader, but since this will always be present we may want to experiment with auto-hiding on scroll like PDF Viewer does (and, slightly different conceptually but effectively the same, Safari when you scroll down).

[mvasilak]

Thinking about this issue, it seems that the primary jobs to be done (JTBD) are

• (a) having multiple items open
• (b1) moving between open items with as little fuss as is possible, ideally in most of the cases with a single tap
• (b2) affecting the items that are more easily accessible, if there are too many (e.g. drag-n-drop to change the tabs order, or automatically making those used last more easily accessible)
• (c) claim as little UI space from the item, making it (dis)appearing dynamically if possible



These could be implemented in several ways, e.g. using a UISegmentedControl, or a UITabBar, or a custom control that is closer to the UI of tabbed panes in the desktop, or some 3rd party library (I’ve seen these 2, https://github.com/xmartlabs/XLPagerTabStrip & https://github.com/uias/Tabman, but I don't think they are what we want). 
We could also consider using a solution much different from tabs, more accustomed to iOS/iPadOS apps. E.g. a sidebar, or a floating control (that would even be visible in full item view), or use some combination of a control with swipe gestures.

Some comments on the JTBDs:

• Just for (a), a solution closer to what apple suggests semantically, would be to use scenes, so an advanced user could utilize something like Split Screen or Stage Manager, and that would be more future-proof for migrating to VisionOS (far-fetched plan, I know).
• JTBD (c) adds an extra tap to change items, when in full view. Of course the dynamic disappearance could be made a user setting, so those users with a large iPad could disable it. But a floating control could be (almost) all the time visible and use a long-press gesture to show a menu of available items, for a somewhat faster path (useful also for drag-n-dropping elements between items).
• JTBD (b) is easier to do when there is a small number of items. It would be nice to know or at least hypothesize, how many items users would open at the same time.

[mvasilak]

@dstillman do you have any comments on the above?

[vancleve]

https://forums.zotero.org/discussion/97817/zotero-ios-recent-documents