The first approach assumed that each view would use one fixed cadence. A monthly report, for example, would show the active month with previous and next controls for moving through adjacent months. This was the clearest and most compact model, but its simplicity depended on limiting what users could select.

The second direction treated period selection as a list of common presets, with a custom range available when none of them matched the user’s needs. I explored two representations: a compact menu placed in the toolbar and a more prominent selector positioned within the content area, with adjacent arrows for moving between periods. Both kept most of the complexity hidden until needed, but they also exposed the limitations of a preset-based model. The toolbar version made sequential navigation difficult, while adding arrows to the second version began reintroducing persistent controls. More importantly, the approach was built around a finite list of expected choices, leaving less common periods and more complex selections to a separate custom flow.

The third direction brought cadence switching and period navigation directly into the main interface so users could change between days, weeks, months, quarters, and years while also moving through periods without opening a separate sheet. Once both actions were made permanently available, however, there was no obvious way to organize them. I explored four representations, including segmented controls with separate navigation, a compact cadence menu, two stacked control rows, and an expanded calendar. Each arrangement offered a different balance between immediate access, clarity, and screen space, but the underlying limitations remained. The controls added persistent complexity to every screen, their hierarchy was difficult to resolve, and reaching a distant period still required either repeated navigation or an additional mechanism.

The final direction separated the persistent representation of time from the controls used to change it. A compact period pill remained visible in the native iOS toolbar across relevant views, showing the active selection and providing a consistent entry point to a dedicated Period Sheet. The sheet could then accommodate cadence switching, nearby and distant navigation, single and multiple selections, and custom ranges without placing that complexity on every screen. This introduced an additional tap before editing the period, but it resolved the larger conflict between keeping time context visible and supporting advanced selections within limited screen space. The separation between the pill and the sheet became the foundational structure of the final system.

Once the pill-and-sheet direction was established, the problem could be divided into two focused components. The pill had the contained responsibility of preserving the active time context and providing a consistent entry point. Most of the interaction model lived inside the Period Sheet, which made it the next and more substantial area of exploration. A conventional bottom sheet containing every available control would have been the easiest solution, but period selection was expected to be a recurring action rather than an occasional configuration task. A large or visually dense sheet would repeatedly obscure the report beneath it and make small period changes feel unnecessarily disruptive. I wanted the sheet to remain as short and unobtrusive as possible without compromising its visual balance, touch targets, or the clarity of its hierarchy.

This balance became more difficult as the sheet expanded across different cadences, navigation methods, and selection types. Its structure needed to accommodate days, weeks, months, quarters, and years, then scale from a single period to multiple periods and custom ranges without feeling like a different component each time. Reaching that point required repeated changes to its density, proportions, control placement, and the options exposed at each stage, gradually reducing its footprint without removing the flexibility that made the direction valuable. The month view became the main reference point for the sheet because it needed to expose enough surrounding context without growing into a full calendar. I explored different sheet heights, navigation placements, grid densities, shortcut positions, and ways of introducing multiselect, gradually reducing the interface until the controls felt compact without becoming crowded or difficult to understand.

Years and quarters required their own layouts because they contain fewer, larger units and create different navigation expectations. I tested several ways of presenting them, ranging from compact grids to more descriptive period blocks, aiming to preserve the same overall hierarchy and interaction patterns used elsewhere without forcing every cadence into an identical structure.

Weeks introduced a different problem because they frequently cross month boundaries and are less easily identified by a single label. The iterations explored how much date information each week needed, how surrounding weeks should be represented, and how users could move through them without losing their position, resulting in a view that remained consistent with the rest of the sheet but was organized around the specific character of weekly navigation.

Early iterations represented every selected period as a removable pill above the grid. This provided explicit feedback and made individual periods easy to remove, but the pattern became increasingly expensive as the selection grew. Horizontal scrolling concealed parts of the selection and became frustrating after only a few items, whereas wrapping the pills onto additional lines continuously increased the sheet’s height. The pills also competed with the period grid despite mostly duplicating information already communicated through selection highlights.

The final direction replaced the pill list with a short summary beneath the sheet title, such as “3 months” or “4 weeks,” and retained highlights as the primary feedback within the period grid. The summary confirmed that a broader selection remained active even after users navigated elsewhere, and highlighted periods could still be removed by selecting them again. This provided less detail at a glance than the pill-based version, but preserved a stable sheet height, avoided horizontal navigation, and scaled consistently as more periods were added.

The cadence-based views worked well for periods that followed calendar boundaries, but they could not represent every way someone might frame time. Some questions begin and end on specific dates, such as the duration of a trip, a project phase, or the period surrounding an event. The original sheet addressed this through a single custom range, which acted as a fallback whenever days, weeks, months, quarters, or years were not precise enough. As the selection model expanded, I reconsidered how this option fitted within the rest of the system. Renaming it from “Custom” to “Day” positioned it as the most granular cadence rather than an exceptional mode, with the calendar allowing users to construct a range from individual days. This created a more consistent structure across the sheet and left room to extend the same interaction beyond one continuous span.

Most of the design challenge concerned feedback and sequencing. The interface needed to communicate which boundary was currently being defined, display the selected start and end dates, and distinguish the first day, last day, and days between them inside the calendar. I avoided adding permanent labels above the date fields because they increased the sheet’s height, using the field placeholders to communicate their purpose instead. The start field receives focus when the view opens, and selecting a date immediately advances the interaction to the end field, reducing the need for an additional step or explicit instruction. A single range still excluded cases involving separate parts of the timeline, so I introduced the ability to link additional ranges into the same selection. Each added range needed its own start and end feedback without turning the sheet into a growing form or pushing it beyond the half-screen detent. The resulting interaction reused the same range-building sequence for every addition and relied on the calendar highlights to communicate the structure of the active range, keeping the more advanced capability within the same compact layout rather than introducing a separate flow.

Once the sheet structure was established, the focus shifted to maintaining continuity as users moved between cadences, navigated through time, and constructed selections. I treated the current position on the timeline and the active selection as separate states, allowing users to explore other periods without accidentally replacing earlier choices. Changing cadence preserved the same temporal context, so moving from a month to its surrounding weeks or year did not feel like starting again

Navigation was adapted to the distance users needed to travel. Arrows and swiping supported movement between adjacent periods, shortcuts provided immediate access to recurring destinations such as the current, previous, or next period, and a higher-level control made distant dates reachable without repeated stepping. These methods served different situations but returned users to the same selection surface. Selection behaviour then adapted to the period being constructed. A single period could be chosen directly, multiselect retained earlier choices through persistent highlights and a compact summary, and custom ranges guided users from the start date to the end date by advancing focus automatically. The same sequence could be repeated to add non-adjacent ranges without introducing another interaction model. Local highlights communicated what was selected in the current view, the summary confirmed selections that might no longer be visible, and the period pill displayed the final result after confirmation.

My initial expectation was that the picker would not need an Apply button because every selection could update the report immediately. This seemed like the most direct interaction for a single period, but the assumption failed once the component was connected to real reporting data. Each update could take roughly five to ten seconds, and constructing a multiselection triggered the same delay after every tap even though the user had not finished defining the intended period. Custom ranges became particularly frustrating, and I began avoiding them despite having designed the picker specifically to support that flexibility.The problem changed the interaction contract rather than only exposing a technical limitation. The picker needed to distinguish the period currently applied to the report from the draft selection being edited inside the sheet, as well as the part of the timeline being browsed. Introducing an explicit confirmation step added one action, but allowed users to complete a single period, several periods, or a custom range before initiating the expensive report update. In practice, this felt more immediate than repeatedly applying incomplete selections.

The underlying reporting performance was improved later, but the separation between editing and applying remained useful beyond the original delay because compound selections naturally contain intermediate states that should not affect the report. This became an important lesson from the implementation: removing a button does not make an interaction direct if the system responds slowly or acts before the user has finished expressing an intention.

The Period Pill had to translate every possible selection into a label that remained understandable outside the sheet. This was straightforward for a year such as “2025,” but became more difficult with relative periods, ranges crossing months or years, and selections containing several separate periods. Showing every boundary would make the pill too wide for the iOS toolbar, whereas aggressive shortening could remove the information that distinguished one selection from another. The label therefore needed to adapt to both the meaning and complexity of the selected period rather than apply one fixed date format.

The logic prioritised familiar relative terms such as “This month,” followed by natural labels for complete calendar units. Ranges removed repeated month or year information when the remaining label stayed unambiguous, then restored that context when crossing a boundary. More complex selections used shorter summaries, but could never present separate periods as one continuous range or omit information required to identify the scope correctly. The pill resized within defined minimum and maximum widths, allowing it to occupy the same toolbar position across time-based views without competing with the screen title or surrounding actions. The rules also needed to accommodate localisation, longer month names, different date orders, narrow screens, and larger text sizes.