Child Task Hierarchy

Executive Summary

The app currently has two hierarchy concepts: subtasks (Notion to_do blocks — lightweight checkboxes with no status, due date, or priority) and child tasks (full Task pages linked via Notion “Parent Task” self-referencing relation, with their own status, due date, priority, and categories).

Decision: Subtasks are being removed. Child tasks are the only hierarchy going forward.

This spike investigated how child tasks should work across the entire app. After competitive analysis of 6 industry leaders, wireframing 5 interactive screens, designing detailed interaction specs, and assessing technical feasibility against the existing codebase, we recommend:

• A flat list with expand/collapse — children render inline under the parent when expanded
• Inline quick-add for child creation in TaskDetail (no navigation required)
• Max 2 levels of nesting (parent → child)
• Lazy-loaded children with local cache for instant re-expand
• Bidirectional completion cascade: auto-complete parent when all children done (with undo); confirmation sheet for completing parent with active children

The backend infrastructure is ~80% built. Estimated total effort: M-L (1.5–2 sprints), reduced from L after agreeing to disable drag on nested tasks for v1.

Spike Deliverables

Key Decisions

These decisions were agreed across the team through PO review, UI designer review, and cross-deliverable synthesis.

UX Research — Competitive Analysis

Studied 6 task management apps across 5 dimensions: creation flow, visual nesting, completion behaviour, navigation, and mobile patterns.

Apps Analysed

Key Findings

• Optimal depth for mobile: 1–2 levels. Apps allowing 4+ levels see usability complaints on small screens. Industry is converging on shallow hierarchies.
• Linear’s bidirectional auto-close is best-in-class. All children done → parent auto-completes. Parent completed → explicit choice for children. We adopted a hybrid of Linear’s model.
• Inline quick-add is universal. Every app studied offers inline creation without navigating away from the parent context.
• Todoist’s visual pattern is our baseline. Dense flat rows, 16px indentation, no connector lines — matches our existing aesthetic.
• Full-featured children > lightweight checklists. Apps with status/date/priority on sub-items (Linear, Todoist) handle complex projects better than checkbox-only approaches (Things 3 checklists).

Wireframes

5 interactive screens designed at 375px mobile viewport, matching the Todoist-dense dark theme aesthetic. View wireframes →

Screen A — Task List (Expand/Collapse)

• Chevron (▶/▼) right of StatusCircle, 32×44px tap target (preserves consistent left edge)
• Child count badge (done/total) right-aligned before due date
• 16px indentation per level, no connector lines

Screen B — Parent Detail View

• Child tasks section replaces deprecated SubtaskList
• Each child shows: StatusCircle + title + due date, tappable to navigate
• Section header: “Child tasks (2/4)” with [+ Add] button
• [+ Add child task] inline form at bottom of child list

Screen C — Child Detail View

• “↳ Parent Title” link at top, navigates to parent detail
• “← Back to [Parent]” button below drag pill indicator
• All standard task fields: status, priority, due date, categories, notes

Screen D — Create Child Task Flow

• Option A (Recommended): Inline quick-add in TaskDetail — text input + date chip + submit
• Option B: Full create form with pre-filled parent
• NLP date parsing via chrono-node (same as QuickAdd)
• Defaults: Status → Inbox, Category → inherited from parent, Priority → None

Screen E — Card Variants

• Parent card: Chevron toggle + child count badge + progress text
• Child card: 16px indent + “↳ Parent Name” breadcrumb
• Standalone card: No hierarchy indicators (existing design)

Interaction Design

Completion Behaviour

Expand / Collapse

• Tap chevron: toggle expand/collapse with 150ms stagger animation (50ms between children)
• Tap task row: opens TaskDetail (does NOT toggle expand)
• Pull to refresh: preserves expand/collapse state
• Persist state in localStorage keyed by expand-state:{viewKey}

Swipe Gestures

• Right swipe (>100px): toggle Done/Inbox — triggers auto-complete check if last incomplete child
• Left swipe (<-100px): reschedule popup — identical to regular tasks
• Edge case: completing last child via swipe → double haptic (child + parent)

Reordering

• Within same parent: long-press drag, stored in localStorage (Notion relations have no sort order)
• Between parents: NOT supported in v1 — use TaskDetail “Change parent” flow
• Drag disabled on child rows and expanded parents (AGREED)

Navigation

• TaskDetail maintains navigation stack: Parent → Child → swipe back → Parent
• Swipe-down from child: returns to parent detail (not dismiss)
• Swipe-down from parent/top-level: dismisses sheet
• Stack depth matches 2-level nesting cap

Edge Cases

Technical Feasibility

What Already Exists (~80% of backend)

Key Gaps

Notion API Constraints

• Querying children: Efficient — single API call with relation filter
• Recursive queries: Not supported — each level requires N additional calls
• Rate limit: 3 req/s per integration — rapid expansion of 5 tasks could take ~2s
• Page-scoped enrichment: parentTitle/childCount only accurate within 100-result query page

Recommendation

Consolidate on child tasks (full Notion pages via “Parent Task” relation). Remove subtasks (to_do blocks) entirely.

Why This Approach

• Unified model: One hierarchy concept instead of two. Eliminates user confusion between “subtask” and “child task.”
• Full capabilities: Child tasks have status, due date, priority, categories — unlike checkbox-only subtasks.
• Infrastructure exists: Backend is ~80% built. The Notion “Parent Task” relation is already in use. Frontend already renders parent links, child counts, and depth indentation.
• Industry alignment: All 6 apps studied use full-featured sub-items (or are moving toward them). Checkbox-only checklists are falling out of favour for task management.
• Incremental delivery: 6 phases, each independently shippable. No big-bang migration required.

What NOT to Do

• Don’t convert existing to_do subtasks to child tasks. Data model mismatch (text-only → full task), high API cost, low user value. Let them age out naturally.
• Don’t support 3+ nesting levels. 375px viewport can’t show it usably; Notion API costs scale per level.
• Don’t add drag-to-reparent in v1. Too error-prone on mobile. TaskDetail-based flow is safer.

Implementation Phases

Ordered by dependency. Total: ~15 working days across 2 sprints. Phases 1 & 2 can run in parallel.

Dependency Graph

Critical path: Phase 1 → Phase 3 → Phase 4 → Phase 5. Phases 1 & 2 run in parallel.

Migration Plan

Strategy: Cut Over, Don’t Convert

Do NOT convert existing to_do block subtasks to child tasks.

• Data model mismatch: Subtasks are text-only checkboxes. Child tasks are full pages with status, due, priority. No meaningful 1:1 mapping.
• API cost: Converting requires N×M API calls (create page + delete block per subtask). Risky on a live Notion database.
• Low user impact: Most subtasks are ephemeral checklists (“Pack X, pack Y”). Users can manually recreate important ones as child tasks.

Migration Phases

What Happens to Existing Subtasks

Existing Notion to_do blocks are not deleted from the Notion database. They remain as block children of their parent page. The PWA simply stops rendering them after Phase C. Users who need those items as child tasks can recreate them manually.

Risk Assessment

Deferred Items