Page Organization Analysis

This document analyzes the current page structure and organization of the SCORM API website, identifying issues with route organization, page grouping, feature clustering, user flow patterns, and redundancy.

Current Route Structure

Public Routes

/                          → Landing page
/features                  → Features page
/pricing                   → Pricing page
/docs                      → Documentation
/api/docs                  → API reference (OpenAPI)
/sign-in                   → Authentication (Clerk)
/sign-up                   → Registration (Clerk)
/onboarding/checkout       → Plan selection and Stripe checkout
/onboarding/success        → Onboarding completion
/legal/fair-use            → Fair use policy

Customer Dashboard Routes

/dashboard                 → Main customer dashboard (user-type aware)
/dashboard/packages        → SCORM packages management
/dashboard/packages/[id]   → Package details
/dashboard/api-keys        → API key management
/dashboard/credentials     → Unified credentials (API keys, webhooks, dispatches)
/dashboard/billing         → Billing and subscription
/dashboard/usage           → Usage metrics and quotas
/dashboard/webhooks        → Webhook configuration
/dashboard/reports         → Reports landing page
/dashboard/reports/custom  → Custom reports builder
/dashboard/reports/learner-progress → Learner progress reports
/dashboard/dispatch        → SCORM Dispatch management
/dashboard/dispatch/create → Create dispatch package
/dashboard/dispatch/[id]   → Dispatch package details
/dashboard/xapi            → xAPI statements viewer

Admin Routes

/admin                     → Admin dashboard
/admin/packages            → All packages (all tenants)
/admin/packages/[id]/distribution → Package distribution settings
/admin/packages/[id]/versions → Package version history
/admin/tenants             → Tenant management
/admin/reports/learner-progress → Learner progress (all tenants)
/admin/reports/custom      → Custom reports (all tenants)
/admin/webhooks            → Webhook management (all tenants)
/admin/api-keys            → API key management (all tenants)
/admin/system              → System settings (if exists)
/admin/audit-logs          → Audit log viewer

Learner Routes

/learner/dashboard         → Learner's learning dashboard
/learner/packages/[id]      → Package view for learners

Player Routes

/player/[sessionId]        → SCORM player (main)
/player/dispatch/[token]    → Dispatch player

API Routes

/api/v1/packages           → Package CRUD
/api/v1/packages/[id]/launch → Launch session
/api/v1/sessions           → Session management
/api/v1/content/[...path]  → Content serving
/api/v1/xapi/statements    → xAPI statements
/api/customer/*            → Customer-specific APIs
/api/admin/*               → Admin-specific APIs
/api/health                → Health check

Route Organization Issues

Issue 1: Inconsistent Route Patterns

Problem: Mixed patterns for similar functionality

Examples:

  • /dashboard/packages (plural) vs /dashboard/api-keys (plural) vs /dashboard/billing (singular)
  • /dashboard/reports/custom (nested) vs /dashboard/dispatch/create (nested) vs /dashboard/xapi (flat)
  • /admin/packages/[id]/distribution (deep nesting) vs /dashboard/packages/[id] (shallow nesting)

Impact:

  • Users can't predict URL structure
  • Hard to remember routes
  • Inconsistent mental models

Issue 2: Unclear Route Grouping

Problem: Routes don't follow logical feature groupings

Current Grouping (by route prefix):

  • /dashboard/* - Customer features
  • /admin/* - Admin features
  • /learner/* - Learner features
  • /player/* - Player features

Issues:

  • /dashboard/xapi - xAPI is a feature, not a dashboard section
  • /dashboard/dispatch - Dispatch is a feature, not a dashboard section
  • /learner/dashboard - Separate from customer dashboard, but same concept

Expected Grouping (by feature):

  • Content Management: Packages, Dispatch
  • Analytics: Reports, Usage, xAPI
  • Configuration: API Keys, Webhooks, Credentials
  • Account: Billing, Usage

Issue 3: Redundant Routes

Problem: Multiple routes for similar functionality

Examples:

  1. Reports Routes:

    • /dashboard/reports (landing)
    • /dashboard/reports/custom (custom reports)
    • /dashboard/reports/learner-progress (learner progress)
    • /admin/reports/custom (admin custom reports)
    • /admin/reports/learner-progress (admin learner progress)

    Issue: Landing page (/dashboard/reports) may be unnecessary if users go directly to specific report types

  2. Credentials Routes:

    • /dashboard/api-keys (API keys only)
    • /dashboard/webhooks (Webhooks only)
    • /dashboard/credentials (All credentials unified)

    Issue: Three routes for related functionality, credentials page not in navigation

  3. Package Routes:

    • /dashboard/packages (customer packages)
    • /admin/packages (all packages)
    • /learner/packages/[id] (learner view)

    Issue: Similar functionality, different contexts, but different route patterns

Issue 4: Missing Route Patterns

Problem: Expected routes don't exist or are inconsistent

Missing:

  • /dashboard/settings (general settings page)
  • /dashboard/integrations (unified integrations page)
  • /admin/settings (admin settings)
  • /admin/integrations (admin integrations)

Inconsistent:

  • Some features have detail pages (/dashboard/packages/[id])
  • Some features don't (/dashboard/api-keys - no detail page)
  • Some features have create pages (/dashboard/dispatch/create)
  • Some features don't (/dashboard/packages - no create page, API only)

Page Grouping Issues

Issue 1: Feature Clustering

Current Clustering:

  • All customer features under /dashboard/*
  • All admin features under /admin/*
  • All learner features under /learner/*

Problems:

  1. Too Broad: /dashboard/* contains 13+ different features
  2. No Sub-grouping: All features at same level
  3. Mixed Concerns: Content, analytics, configuration, account all mixed

Better Clustering (by function):

  • Content: /content/packages, /content/dispatch
  • Analytics: /analytics/reports, /analytics/usage, /analytics/xapi
  • Integrations: /integrations/api-keys, /integrations/webhooks
  • Account: /account/billing, /account/usage, /account/settings

Issue 2: Context Separation

Current: Routes separated by user role (customer/admin/learner)

Issues:

  • Admins who are also customers see duplicate functionality
  • Learner features separate from customer features (but same users)
  • No unified view for multi-role users

Better: Routes organized by feature, with role-based access control

Issue 3: Nested vs. Flat Structure

Current: Mixed nesting patterns

Examples:

  • /dashboard/reports/custom (nested)
  • /dashboard/dispatch/create (nested)
  • /dashboard/xapi (flat)
  • /dashboard/usage (flat)

Issues:

  • No consistent pattern
  • Users can't predict structure
  • Some features feel "deeper" than others (unintended hierarchy)

Feature Clustering Analysis

Current Feature Distribution

Customer Dashboard (/dashboard/*):

  1. Packages (content)
  2. API Keys (integration)
  3. Credentials (integration - unified)
  4. Billing (account)
  5. Usage (analytics)
  6. Webhooks (integration)
  7. Reports (analytics)
  8. Custom Reports (analytics)
  9. Learner Progress (analytics)
  10. Dispatch (content)
  11. xAPI (analytics)

Issues:

  • 4 different feature types in one route group
  • No logical grouping
  • Hard to find related features
  • Cognitive overload

Recommended Feature Clusters

Cluster 1: Content Management

  • Packages
  • Dispatch
  • (Future: Content library, templates)

Cluster 2: Analytics & Reporting

  • Reports
  • Custom Reports
  • Learner Progress
  • Usage Metrics
  • xAPI Statements

Cluster 3: Integrations

  • API Keys
  • Webhooks
  • Credentials (unified)

Cluster 4: Account & Settings

  • Billing
  • Usage Quotas
  • Settings (if added)
  • Profile

User Flow Patterns

Pattern 1: Content Workflow

Current Flow:

  1. /dashboard → Click "SCORM Packages" widget
  2. /dashboard/packages → View packages
  3. Upload via API (external)
  4. Refresh /dashboard/packages
  5. Click package → /dashboard/packages/[id]
  6. Click "Launch" → /player/[sessionId]

Issues:

  • Upload step is external (API), breaks UI flow
  • No upload UI in dashboard
  • Must know API to upload

Better Flow:

  1. /dashboard → Click "SCORM Packages"
  2. /dashboard/packages → Click "Upload Package"
  3. /dashboard/packages/upload → Upload UI
  4. /dashboard/packages/[id] → View package
  5. Click "Launch" → /player/[sessionId]

Pattern 2: Analytics Workflow

Current Flow:

  1. /dashboard → Click "Reports" widget
  2. /dashboard/reports → Landing page
  3. Click "Learner Progress" → /dashboard/reports/learner-progress
  4. Or click "Custom Reports" → /dashboard/reports/custom

Issues:

  • Extra click through landing page
  • Landing page may not add value
  • Two separate report types, but similar functionality

Better Flow:

  1. /dashboard → Click "Reports"
  2. /dashboard/reports → Unified reports page with tabs
  3. Switch between "Learner Progress" and "Custom" tabs
  4. Or direct links: /dashboard/reports?tab=learner-progress

Pattern 3: Configuration Workflow

Current Flow:

  1. /dashboard → Click "API Keys"
  2. /dashboard/api-keys → Manage API keys
  3. Back to /dashboard
  4. Click "Webhooks"
  5. /dashboard/webhooks → Manage webhooks

Issues:

  • Multiple pages for related functionality
  • Must navigate back and forth
  • Credentials page exists but not in navigation

Better Flow:

  1. /dashboard → Click "Integrations" or "Credentials"
  2. /dashboard/integrations → Unified page with tabs
  3. Switch between "API Keys", "Webhooks", "Dispatch Tokens" tabs

Redundancy Issues

Redundancy 1: Reports Landing Page

Current:

  • /dashboard/reports (landing page)
  • /dashboard/reports/custom (custom reports)
  • /dashboard/reports/learner-progress (learner progress)

Issue: Landing page may be unnecessary if users go directly to specific report types

Options:

  1. Remove landing page, make /dashboard/reports redirect to most-used report type
  2. Make landing page a unified reports interface with tabs
  3. Keep landing page but make it more useful (overview, quick stats)

Redundancy 2: Credentials Pages

Current:

  • /dashboard/api-keys (API keys only)
  • /dashboard/webhooks (Webhooks only)
  • /dashboard/credentials (All credentials unified)

Issue: Three pages for related functionality, credentials page not in navigation

Options:

  1. Remove individual pages, use only unified credentials page
  2. Keep individual pages, add credentials page to navigation
  3. Make credentials page the main page, individual pages as detail views

Redundancy 3: Admin vs. Customer Routes

Current:

  • /dashboard/packages (customer packages)
  • /admin/packages (all packages)
  • /dashboard/reports/custom (customer reports)
  • /admin/reports/custom (all tenant reports)

Issue: Similar functionality, different contexts, but completely separate routes

Options:

  1. Use query parameters: /packages?context=customer vs /packages?context=admin
  2. Use route parameters: /packages/[context]
  3. Keep separate but ensure consistent patterns

Redundancy 4: Package Detail Routes

Current:

  • /dashboard/packages/[id] (customer view)
  • /admin/packages/[id] (admin view, may not exist)
  • /learner/packages/[id] (learner view)

Issue: Same package, different views, different routes

Options:

  1. Single route with context: /packages/[id]?context=customer|admin|learner
  2. Keep separate but ensure consistent functionality
  3. Use shared components with different layouts

Inconsistent Page Patterns

Pattern 1: List vs. Detail Pages

Current:

  • /dashboard/packages (list) → /dashboard/packages/[id] (detail) ✅
  • /dashboard/api-keys (list) → No detail page ❌
  • /dashboard/webhooks (list) → No detail page (but can view in list) ⚠️
  • /dashboard/dispatch (list) → /dashboard/dispatch/[id] (detail) ✅

Issue: Inconsistent pattern - some features have detail pages, some don't

Pattern 2: Create Pages

Current:

  • /dashboard/dispatch/create (has create page) ✅
  • /dashboard/packages (no create page, API only) ❌
  • /dashboard/api-keys (create in modal/on-page) ⚠️
  • /dashboard/webhooks (create in modal/on-page) ⚠️

Issue: Inconsistent patterns - some use dedicated pages, some use modals

Pattern 3: Settings/Configuration Pages

Current:

  • /dashboard/billing (has settings) ✅
  • /dashboard/usage (view only, no settings) ⚠️
  • No general settings page ❌
  • No account settings page ❌

Issue: Settings scattered or missing


Unclear Page Purposes

Page 1: /dashboard/reports

Current Purpose: Landing page for reports

Issues:

  • Unclear what it does (just links to other pages?)
  • May be unnecessary intermediate step
  • Doesn't provide value beyond navigation

Recommendation: Either make it a unified reports interface or remove it

Page 2: /dashboard/credentials

Current Purpose: Unified view of API keys, webhooks, and dispatch tokens

Issues:

  • Not in navigation (hidden feature)
  • Purpose unclear (why separate from individual pages?)
  • May duplicate functionality of individual pages

Recommendation: Add to navigation or consolidate with individual pages

Page 3: /dashboard/xapi

Current Purpose: View xAPI statements

Issues:

  • Not in navigation (hidden feature)
  • Unclear relationship to other analytics (Reports, Usage)
  • May be redundant with Reports functionality

Recommendation: Integrate into Reports or add to navigation

Page 4: /admin/system

Current Purpose: System settings (if exists)

Issues:

  • May not exist (route found but page may not be implemented)
  • Unclear what "System" contains
  • Vague naming

Recommendation: Clarify purpose or remove if not implemented


Route Depth Analysis

Shallow Routes (1-2 levels)

Examples:

  • /dashboard/packages
  • /dashboard/api-keys
  • /dashboard/billing
  • /dashboard/usage
  • /dashboard/xapi

Pros: Easy to remember, quick to type Cons: All at same level, no hierarchy

Medium Routes (2-3 levels)

Examples:

  • /dashboard/packages/[id]
  • /dashboard/reports/custom
  • /dashboard/dispatch/create
  • /admin/packages/[id]/distribution

Pros: Shows hierarchy, groups related pages Cons: Inconsistent depth, some feel "deeper" than others

Deep Routes (3+ levels)

Examples:

  • /admin/packages/[id]/distribution
  • /admin/packages/[id]/versions
  • /dashboard/dispatch/[id] (if has sub-pages)

Pros: Clear hierarchy, organized Cons: Long URLs, harder to remember

Issue: Inconsistent depth makes navigation unpredictable


Missing Route Patterns

Pattern 1: Settings Routes

Missing:

  • /dashboard/settings (general settings)
  • /dashboard/settings/profile (profile settings)
  • /dashboard/settings/notifications (notification preferences)
  • /admin/settings (admin settings)

Impact: Settings scattered or missing

Pattern 2: Help/Support Routes

Missing:

  • /help (help center)
  • /support (support tickets)
  • /docs/getting-started (onboarding guide)

Impact: Users don't know where to get help

Pattern 3: Search Routes

Missing:

  • /search (global search)
  • /dashboard/search (dashboard search)

Impact: Can't search for content or features

Pattern 4: Activity/History Routes

Missing:

  • /dashboard/activity (recent activity)
  • /dashboard/history (action history)

Impact: Can't see what happened recently


Page Consolidation Opportunities

Opportunity 1: Reports Consolidation

Current: 3 separate pages

  • /dashboard/reports (landing)
  • /dashboard/reports/custom
  • /dashboard/reports/learner-progress

Proposed: 1 unified page with tabs

  • /dashboard/reports (unified interface)
  • Tabs: "Learner Progress", "Custom Reports", "Usage Analytics"

Benefits:

  • Single page to learn
  • Easier navigation
  • Consistent interface

Opportunity 2: Integrations Consolidation

Current: 3 separate pages

  • /dashboard/api-keys
  • /dashboard/webhooks
  • /dashboard/credentials (unified, but hidden)

Proposed: 1 unified page with tabs

  • /dashboard/integrations (unified interface)
  • Tabs: "API Keys", "Webhooks", "Dispatch Tokens"

Benefits:

  • Related features together
  • Easier to understand relationships
  • Single navigation item

Opportunity 3: Analytics Consolidation

Current: 3 separate pages

  • /dashboard/reports (various report types)
  • /dashboard/usage (usage metrics)
  • /dashboard/xapi (xAPI statements)

Proposed: 1 unified analytics page

  • /dashboard/analytics (unified interface)
  • Sections: "Reports", "Usage", "xAPI"

Benefits:

  • All analytics in one place
  • Easier to compare metrics
  • Consistent interface

Route Naming Inconsistencies

Inconsistency 1: Singular vs. Plural

Current:

  • /dashboard/packages (plural) ✅
  • /dashboard/api-keys (plural) ✅
  • /dashboard/billing (singular) ⚠️
  • /dashboard/usage (singular) ⚠️

Issue: No consistent pattern

Recommendation: Use plural for list pages, singular for action/settings pages

Inconsistency 2: Kebab-case vs. camelCase

Current:

  • /dashboard/api-keys (kebab-case) ✅
  • /dashboard/learner-progress (kebab-case) ✅
  • All routes use kebab-case ✅

Status: Consistent (good)

Inconsistency 3: Abbreviations

Current:

  • /dashboard/xapi (abbreviation) ⚠️
  • /dashboard/api-keys (full words) ✅

Issue: xAPI is an abbreviation, may not be clear to all users

Recommendation: Consider /dashboard/xapi-statements or /dashboard/learning-records


Summary of Critical Issues

High Priority Issues

  1. Inconsistent Route Patterns (mixed nesting, singular/plural)
  2. Missing Navigation Links (Credentials, xAPI not in nav)
  3. Redundant Routes (Reports landing, Credentials pages)
  4. Unclear Page Purposes (Reports landing, Credentials, xAPI)
  5. No Feature Grouping (all features at same level)

Medium Priority Issues

  1. Inconsistent Detail Pages (some have, some don't)
  2. Mixed Create Patterns (pages vs. modals)
  3. Missing Settings Routes (no unified settings)
  4. Route Depth Inconsistency (shallow vs. deep)
  5. No Search Routes (can't search)

Low Priority Issues

  1. Missing Help Routes (no help center)
  2. Missing Activity Routes (no activity feed)
  3. Abbreviation Usage (xAPI may be unclear)

Recommendations Summary

  1. Consolidate Related Pages (Reports, Integrations, Analytics)
  2. Add Missing Navigation Links (Credentials, xAPI)
  3. Standardize Route Patterns (consistent nesting, naming)
  4. Implement Feature Grouping (Content, Analytics, Integrations, Account)
  5. Add Breadcrumbs (show navigation path)
  6. Create Unified Interfaces (tabs instead of separate pages)
  7. Add Settings Routes (unified settings pages)
  8. Clarify Page Purposes (remove or improve unclear pages)
  9. Standardize Detail Pages (consistent pattern)
  10. Add Search Functionality (global and dashboard search)

These recommendations will be detailed in the proposed page organization document.