Repeat rules: show the next real occurrence

Separate recurrence from reminder and time choices.

TickTick presents Time, Reminder and Repeat as separate rows inside Date & Repeat. Mindway combines frequency and an optional end date with Any time of the day and No reminder. These screens help show that a schedule pattern, a due time and an alert are different parts of a task.

Keep those distinctions in the saved summary. “Every Monday, no reminder” should remain understandable without reopening a form. If the user denies notifications, preserve the recurrence and explain the alert limitation instead of suggesting that the whole schedule failed. Conversely, enabling reminders should not create repetition that was never requested.

When the time is intentionally unspecified, avoid silently substituting a midnight notification. If the product needs a default due time, disclose it and let the person change it. A rule editor should not make people learn its defaults by receiving an unexpected alert later.

Show how the interval relates to the starting point.

Routine Planner Habit Tracker combines a weekly mode, selected weekdays, an interval picker and Start date. Chillio shows a task date, Every 2 days and an end-date control. The relationship between those fields determines the actual sequence, not merely the appearance of the frequency selector.

For every-two-week rules, define which week is the starting week. For every-two-day rules, define the anchor date. Display the first few resulting dates so users can catch an unintended offset before saving. The preview should be produced by the same rule logic that schedules the task, not by an independent sentence generator.

If the start date changes, preserve the intended interval and explain any effect on selected weekdays. Avoid silently moving the first occurrence into the past or choosing a different week. A person returning to edit a rule needs to recognize the saved schedule rather than reconstruct its original anchor from memory.

Make end conditions part of the rule, not an afterthought.

Todoery offers endless repetition, an end date and repeat counts in the same configuration flow. minical combines month-based choices, a calendar and End Repeat. These controls expose different ways to bound a series, which should lead to an equally clear saved summary.

Define whether the end date is inclusive and what a repeat count counts. Is it the total number of occurrences including the first, or additional repeats after the initial item? Do not make users discover that distinction after the series ends too early. A preview of the first and final dates can resolve the ambiguity without requiring scheduling terminology.

A selected day number and the last day of the month are different rules. If the user chooses the 31st, explain the policy for shorter months rather than assuming that a picker label settles it. Treat any conflict between a temporary control value and a saved summary as a draft-state question to resolve, not automatic evidence that another app is broken.

Offer familiar presets without hiding their exact meaning.

Plan Joy lists daily, weekly, monthly, yearly and weekday choices with a custom path. Calendars adds explicit workday and weekend presets. These options reduce setup work when they match the user’s intent, but names such as workday can carry assumptions about locale and an individual’s working week.

Show the actual included days for presets that are not universal. “Monday to Friday” is more precise than a bare Workdays label when the product does not support a custom work calendar. Keep an escape into a custom rule so a person with a different schedule can express their intent without creating several unrelated tasks.

A premium badge can describe access to a custom option, but it should not make a selected rule appear saved when the feature is unavailable. If an upgrade is declined, leave the existing valid schedule intact. Do not replace it silently with a simpler preset whose dates differ from what the person reviewed.

Confirm the sentence the controls have built.

TeddyCare shows selected weekdays, a repeat summary and Apply. Amie lists time-specific recurrence descriptions and keeps Cancel and Confirm visible. Both give the user something more recognizable than a row of raw frequency inputs: a statement of the schedule they are about to use.

Keep a temporary editing rule separate from the committed series. Cancel should leave the old schedule unchanged, including any exceptions. If the editor has nested sheets, make it clear whether Apply closes only the recurrence sheet or saves the whole task. A user should not leave believing a draft rule was committed when the parent form still requires Save.

Series editing needs scope as well as confirmation. Google’s recurring-event help distinguishes setting a frequency and end condition from choosing which events an edit affects. For your product, expose the affected occurrences before applying a change, especially when past items or exceptions would otherwise be altered.

Use one rule model for preview and execution.

Store the recurrence definition separately from individual occurrences, completion state and notification preferences. The rule needs a stable identity, anchor, interval, relevant days, end condition and the timezone policy the product supports. Avoid reconstructing it from a translated display sentence; that sentence is a view of the rule, not its source of truth.

Define edge cases with engineering: shorter months, leap years, time-zone travel, clock changes and edits after an occurrence is completed. If the product offers repetition relative to completion rather than a fixed calendar, treat that as another rule type with an explicit explanation. None of the selected screens establishes that all example apps support that behaviour.

For series edits, preserve deliberate exceptions and explain whether a change applies to one occurrence, future occurrences or the full series. Reject invalid combinations before committing and keep the valid draft available for correction. Retrying a failed save should not create a second recurring series.

Test the dates that the user expects to see.

Ask participants to create a two-week schedule on two selected weekdays with a defined end condition. Before saving, ask them to name the next three dates. Compare that expectation with the preview and actual generated occurrences. Repeat after moving the start date and after editing only a future portion of the series.

Use automated fixtures for month ends, a leap day, timezone changes and the product’s chosen daylight-saving policy. The purpose is not to assume one universal answer, but to verify that the documented rule and visible summary match execution. Include a no-reminder case so calendar recurrence is not accidentally coupled to notification delivery.

Track schedule corrections, duplicate-series creation and reports of missing or unexpected occurrences. Keep completion and reminder engagement separate from rule correctness. For accessibility, announce selected weekdays and the interval with meaningful names; a row of one-letter circles should not be the only representation of the resulting schedule.

Review the repeat rule before saving.

Use these checks on a working build, not only on the polished reference state.

• ✓Keep recurrence distinct from time and reminders.
• ✓Show the anchor and first upcoming dates.
• ✓Define end-date inclusivity and count semantics.
• ✓Explain month-end and timezone policies.
• ✓Separate draft Apply from committed task Save.
• ✓Preserve exceptions and make series-edit scope explicit.

Related design decisions

Use the calendar scheduling examples for the surrounding date-selection task while keeping series construction focused on its own rule.

Notification delivery is a separate preference. Compare the notification settings examples when deciding how alerts respect a recurring schedule and user permission.