Calendar view

Problem Context

• Events belong to specific dates, times, ranges, resources, people, rooms, services, calendars, or availability windows.
• Users compare days, weekdays, work hours, all-day items, multi-day spans, overlapping appointments, recurrence, and open slots.
• Calendar data may include tentative, cancelled, busy, free, out-of-office, unavailable, hidden, recurring, shared, or permission-limited events.
• The same surface may support passive inspection, event creation, slot selection, drag or resize, event details, reminders, export, or subscription.
• Timezone, locale, first day of week, daylight saving changes, and mobile density can change what users believe they are booking.

Selection Rules

• Choose calendar view when the main question is what is scheduled when, how long it lasts, whether it overlaps, and what slots remain open.
• Use date picker when the user is choosing one date for a field and does not need to inspect multiple event blocks.
• Use timeline when users need a readable history or sequence for one object rather than a spatial time grid.
• Use list view or agenda when the interval is narrow and users need fast scanning more than spatial comparison.
• Use table or data grid when users need dense sorting, filtering, export, or column comparison across events.
• Use Kanban board when event items are primarily managed by workflow status rather than date and time position.
• Show active view mode, visible range, timezone, today, selected date, hidden events, and event counts near the calendar.
• Represent all-day, timed, multi-day, recurring, tentative, cancelled, unavailable, busy/free, and conflicting events distinctly.
• Expose overflow through a count and a detail surface instead of clipping events in a date cell.
• Avoid drag and resize behavior unless constraints, conflicts, keyboard alternatives, undo, and save feedback are designed.
• Switch to agenda, day, or selected-date detail on narrow screens when month or week cells cannot preserve event identity.
• Do not imply availability from an empty cell unless hidden calendars, permissions, resource constraints, and working hours are accounted for.

Required States

• Default calendar state with visible range, view mode, timezone, today marker, selected date, and event count.
• Month, week, day, and agenda or selected-day detail states when the product offers multiple modes.
• Previous, next, today, and jump-to-date navigation states.
• Event detail, create event, edit event, drag or resize preview, conflict, save pending, save failed, and undo states when editing is supported.
• Overflow state for crowded days with a visible count and accessible popover or drill-in behavior.
• Empty day, empty range, loading, failed-load, offline, permission-limited, hidden-calendar, and out-of-range states.
• All-day, timed, multi-day, recurring, cancelled, tentative, unavailable, busy, free, and current-time states.
• Responsive agenda or day-bar state where event title, time, status, and selected date stay readable.

Interaction Contract

• Calendar navigation changes the visible date range without clearing the selected calendar, selected date, active filters, or opened event unless the user leaves the context.
• Mode switches between month, week, day, and agenda preserve the closest equivalent date and explain when the same event appears differently.
• Each event keeps stable identity, title, start, end, all-day status, calendar/source, and status across navigation, filtering, overflow, and detail views.
• Overflow controls reveal hidden events for the same date without losing the current range or selected day.
• Creating, dragging, or resizing an event previews the target date, time, duration, resource, and conflict before save.
• Conflicts, unavailable slots, permissions, cancelled status, and timezone changes block or warn at the moment the user can still recover.
• Keyboard users can reach date navigation, mode controls, days, event blocks, overflow, and details without tabbing through every empty cell in large grids.
• Mobile or narrow layouts switch to a usable agenda/day pattern rather than hiding event identity in tiny cells.

Implementation Checklist

• Define event schema: id, title, start, end, all-day flag, timezone, calendar/source, owner, resource, recurrence, status, location, conflict state, visibility, and edit permissions.
• Choose supported modes intentionally: month for long-range scanning, week/day for timed placement, agenda/list for narrow screens or dense event lists, resource view for people, rooms, or equipment.
• Implement previous, next, today, jump-to-date, mode switch, selected day, event detail, overflow, and current-time behavior before styling.
• Model crowded days, overlapping timed events, unavailable hours, hidden calendars, permission-limited events, cancelled events, tentative events, recurrence exceptions, and DST boundaries.
• Provide accessible names for dates, event blocks, overflow counts, navigation controls, and mode controls.
• Preserve focus after navigation, mode switch, overflow close, event save, drag failure, and detail close.
• Provide non-drag alternatives for moving or resizing events, including explicit date and time fields.
• Test first-day-of-week locale, timezone display, daylight saving transitions, long event titles, all-day and multi-day events, mobile agenda, and print or export if supported.

Common Generated-UI Mistakes

• Using calendar view as a decorative month card for unscheduled content.
• Showing colored dots without event names, counts, or selected-day details.
• Hiding overflowed events in a crowded date cell.
• Letting drag and resize silently create schedule conflicts.
• Mixing local display time and saved timezone without disclosure.
• Treating empty cells as available when other calendars, permissions, or resources are hidden.
• Forcing users to use a full calendar view for one remembered date.
• Crushing month or week grids on mobile instead of providing an agenda fallback.

Critique Questions

• What does spatial placement answer here: weekday, duration, overlap, availability, resource, or recurrence?
• Can users tell which date range, timezone, view mode, calendars, and filters are visible?
• What happens when a day has too many events to fit?
• Can users inspect all-day, multi-day, recurring, cancelled, tentative, hidden, and unavailable events?
• If events can move, where are conflicts, constraints, keyboard alternatives, undo, and save feedback handled?
• Would date picker, timeline, list view, table, data grid, or Kanban board better fit the task?