Timesheet Header — Restructure Exploration
The core problem: date display lives on the left, but its navigation controls (calendar picker, ← →) are stranded on the right. This violates the proximity principle — related controls should be visually grouped. Here are four approaches.
Current State
Problem
Date on the left, navigation controls on the right. Users must scan across the full header width to connect "what date am I on" with "how do I change it."
Problem: ~500px separates the date from its controls. The calendar icon and arrows are semantically "date navigation" but are positioned as if they belong to the hours summary region.
Variant A
Segmented Date Control
Combine the date, arrows, and calendar picker into a single compound component — like Google Calendar's header. Everything date-related is one visual unit. Clicking the date text opens the mini calendar.
Strengths
- Strongest grouping — zero ambiguity about what controls the date
- Arrows are always visible (no discoverability issue)
- Proven pattern (Google Cal, Outlook, Harvest desktop)
Concerns
- Left side is busier than before
- Separate calendar icon is gone — relies on clicking the date text (needs clear affordance)
Variant B
Hover-Reveal Arrows (Your Initial Direction)
Arrows appear only when hovering the date region. The date itself is clickable to open the calendar. Clean default state, progressive disclosure on interaction. A "Today" chip stays visible as a quick-return anchor.
Hover over the date area to see the arrows appear. This is the approach you mentioned — arrows hidden until you engage with the date zone.
Strengths
- Cleanest default state — minimal visual noise
- Date region still clearly interactive (caret hint + hover background)
- Good for power users who use keyboard shortcuts (←→) anyway
Concerns
- Discoverability — new users won't know arrows exist until they hover
- No hover on mobile/tablet — needs a fallback (always-visible or swipe)
- Likely pushback point: "where did the arrows go?"
Variant C
Flanking Arrows, Separate Calendar Trigger
Arrows sit on either side of the date (always visible). A small calendar icon remains as an explicit "jump to date" affordance. This is the most conservative restructure — it just moves the existing controls to the left without changing interaction patterns.
Strengths
- Lowest-risk change — everything is still explicitly visible
- Keeps the calendar icon as a separate, discoverable affordance
- Works identically on touch and pointer devices
- Easiest to defend against "where did X go" pushback
Concerns
- Left side has 5 elements: sidebar + divider + ← + date + → + calendar + today
- Doesn't reduce visual complexity — just relocates it
Variant D
Centered Date Navigation
Date becomes the hero element at the center of the header — flanked by arrows. This follows the pattern used in many native calendar apps (iOS Calendar, Fantastical). Hours and actions anchor to the right. The date commands attention because it's the primary context for everything on the page.
Strengths
- Strongest hierarchy — the date is the most important context, and it looks it
- Natural eye-flow: sidebar → (scan center) date → (scan right) summary
- Clean separation: left = navigation, center = context, right = data + actions
Concerns
- Bigger layout shift from current — may feel unfamiliar to existing users
- Center positioning can collide with hours group on narrow viewports
- "Today" button is now isolated on the left away from the date (could also go center)
Recommendation
Start with Variant A, prototype B as a progressive enhancement
Variant A (segmented control) is the safest bet because it solves the proximity problem completely, uses a proven pattern, and keeps arrows always discoverable. The "Today" button is a nice bonus that the current design lacks.
Variant B (hover-reveal) is worth prototyping as a refinement on top of A — once users learn the date is clickable, you could progressively hide the arrows. But it shouldn't be the starting point because you'll lose the argument on discoverability.
Variant D (centered) is the strongest from an information architecture standpoint, but it's the biggest departure and creates responsive layout challenges. Worth considering for a larger redesign.