- Home
- Design notes
- Alphabetical Index Analysis
UI/UX Analysis: Cards vs. Alphabetical Index for Nested Pages
Date: February 2026 Context: Mobile navigation redesign for nested article listings
Problem Statement
The site has deeply nested content with varying item counts:
| Section | Subsection | Article Count |
|---|---|---|
| Adhyatmachutukes | Hari, Vayu and Haridaasas | 46 |
| Adhyatmachutukes | Likucha Vamsha and MadhwaVijaya | 37 |
| Adhyatmachutukes | From the Raamayana | 29 |
| Adhyatmachutukes | The Intangible Aspects of the Body | 17 |
| Songs | Madhwaachaarya | 13 |
Current implementation: Nested pages with many articles use a simple bulleted list, which becomes overwhelming for 20+ items.
Current State Assessment
Where Cards Work Well
| Page Type | Example | Item Count | Effectiveness |
|---|---|---|---|
| Hub Menu | Homepage menu | 10 sections | Excellent |
| Section Index | /songs/ | 3 composers | Excellent |
| Section Index | /adhyatmachutukes/ | 8 themes | Good |
| Section Index | /books/ | 3 books | Excellent |
Where Current Design Breaks Down
Nested pages with many articles (e.g., /adhyatmachutukes/Hari, Vayu and Haridaasas/) use a bulleted list that creates:
- Cognitive overload - wall of 46 links with no organization
- No landmarks - users lose position while scrolling
- No predictability - items appear in file-system order
- Long scroll - ~4700px for 46 items on mobile
Proposed Solution: Alphabetical Index
Visual Concept
┌─────────────────────────────────┐
│ ← Back │
│ │
│ Hari, Vayu and Haridaasas │
│ 46 articles │
│ │
│ [A][B][D][G][H][J][K][L][M]... │ ← Jump nav (sticky)
├─────────────────────────────────┤
│ │
│ A │ ← Letter header
│ ─────────────────────────────── │
│ Ananda Daasa Part 1 │
│ Ananda Daasa Part 2 │
│ │
│ B │
│ ─────────────────────────────── │
│ Bhootharaja │
│ │
│ D │
│ ─────────────────────────────── │
│ Dasaavani │
│ Dwaadasha Stothra │
│ │
└─────────────────────────────────┘
Comparative Analysis
| Criterion | Current (Bulleted List) | Alphabetical Index |
|---|---|---|
| Findability | Poor - must scan all items | Good - jump to letter |
| Scanability | Poor - no visual breaks | Good - letter headers |
| Mental model | None - random order | Familiar - like contacts |
| Cognitive load | High - wall of text | Lower - chunked |
| Location awareness | None | Letter headers show position |
Advantages of Alphabetical Index
- Predictable location - users know where to find items
- Jump navigation - tap letter to skip instantly
- Visual chunking - letter headers break the wall of links
- Familiar pattern - mirrors contacts app, dictionary
- Scales well - works for 20 or 200 items
Disadvantages / Concerns
- Semantic grouping broken - thematically related articles scatter across letters
- "The" problem - "The Demons" under T or D? (Recommend: strip "The" for sorting)
- Single-item letters - "B" with just one item looks sparse
- Doesn't help discovery - if you don't know what you're looking for, alphabetical doesn't help
- Multi-part articles - "Part 1", "Part 10" must sort numerically
Recommendation: Hybrid Approach
| Page Type | Recommended UI |
|---|---|
| Hub Menu | Cards (keep as-is) |
| Section Index (Songs, Books) | Cards (keep as-is) |
| Nested pages with < 15 items | Simple list (keep as-is) |
| Nested pages with 15+ items | Alphabetical index |
This targets the actual pain point without over-engineering smaller sections.
Implementation Considerations
- Threshold - apply alphabetical only when item count > 15
- "The" handling - sort "The Demons" under D, display as "The Demons"
- Jump nav - only show for 20+ items (sticky letter bar)
- Empty letters - don't show letters with no content
- Number handling - articles starting with numbers go before A
- Part numbering - ensure "Part 1", "Part 2", "Part 10" sort numerically
Files Involved
app/overrides/partials/content.html- back button navigationapp/overrides/assets/stylesheets/custom.css- card and index stylingapp/overrides/assets/javascripts/custom.js- hub menu logic- Individual index.md files for sections
Status
Analysis complete. Implementation pending based on prioritization.