User Experience 1.0: Community Platform & Personalization

[fatherlinux]

Overview

ROTV currently delivers well on FOMO elimination — see what's happening without checking 12 sites. But discovery is passive (zoom and tap), and the site treats every visitor identically. UX 1.0 transforms ROTV from a read-only aggregator into a community platform with identity, giving users a reason to log in, engage, and contribute.

This aligns with the PR/FAQ's open source positioning: "The same people who maintain trails, lead hikes, and organize cleanups can contribute to ROTV."

---

Features (Priority Order)

Phase 1: Low-Hanging Fruit

1. Navigation Intent Button

• What: "Directions" button on every POI sidebar that opens Google Maps (or Apple Maps on iOS) with coordinates
• Why: Bridges the gap between discovery and actually going there. One tap from "I found something interesting" to "I'm driving there"
• Effort: Trivial — coordinate data already exists

Phase 2: User Identity & Engagement

2. Want to Visit List (Watchlist)

• What: Logged-in users can add any POI to a "Want to Visit" list
• Why: Gives users a reason to log in. Transforms the homepage — "here's what's happening at places you care about." Powers personalization for email (Add Cost, Limited Mobility and Hours Fields for Activities #7) and the personalized home (Add editable Drive ID fields in Settings #9)
• UX: Heart/bookmark icon on POI cards and sidebar. Dedicated "My List" view

3. Visited List

• What: Users can mark POIs as visited
• Why: Feeds badge earning (Simplify Google Drive Integration #8), powers recommendations ("you visited 4 Metroparks reservations, here are 3 you haven't been to"), and gives a sense of completeness/progress
• UX: Check/visited toggle on POI sidebar. Progress stats ("You've explored 23 of 371 locations")

4. Save News & Events

• What: Bookmark individual news articles and events for later reference
• Why: Events are time-sensitive — users find something Wednesday and want to remember it for Saturday
• UX: Bookmark icon on news/event cards. "Saved" section in user profile

5. Like News & Events

• What: Anonymous like counts on news articles and events
• Why: Dual purpose — social proof for users AND curation signal to surface interesting content. Feeds "most liked this week" for the weekly email (Add Cost, Limited Mobility and Hours Fields for Activities #7)
• UX: Heart button with count. Keep anonymous (not social-graph style) — privacy matters for a community project
• Design note: Likes should be anonymous counts, not Facebook-style "Scott liked this"

Phase 3: Community Contribution

6. Community Submissions

• What: Logged-in users can submit new Events, News, and POIs that feed into the existing moderation queue
• Why: PR/FAQ explicitly promises this ("Community submissions are on the roadmap"). This is what makes ROTV a community project instead of a single-maintainer data operation
• UX: Simple form, logged-in only, dumps into the existing moderation queue. Don't build a separate workflow — the AI content pipeline and community submissions share the same review process
• Submission types: Events (date, location, description, source URL), News (URL, location association), POIs (name, location, description, coordinates)

7. Public MCP Server

• What: Read-only MCP server with tools like search_pois, get_trail_status, get_upcoming_events, get_news
• Why: Turns ROTV into an API platform. Someone's AI agent asks "what's open for mountain biking today?" and gets a structured answer. That's the PR/FAQ's 2-minute experience, fully automated. No other regional outdoor site has this
• Effort: Moderate — the read-only admin MCP server (30 tools) already exists. Public version is a subset with auth/rate-limiting
• Differentiator: Unique in the outdoor/parks space

Phase 4: Retention & Growth

8. Weekly Mailing List

• What: Weekly email digest — "What's happening in the valley this weekend"
• Why: Proactive delivery of the PR/FAQ's core promise. Brings users back weekly
• Personalization: If user has a watchlist (Move Property Owners to Manageable System #2), prioritize events at those locations. If not, fall back to valley-wide highlights. "Most liked this week" (Add Governance and Richer Testing #5) as a section
• Depends on: Move Property Owners to Manageable System #2 (watchlist) and Add Governance and Richer Testing #5 (likes) for personalization data

9. Badge System with Promotions

• What: Achievement badges tied to physical-world exploration, not clicks
• Why: Retention loop. Creates personas that match PR/FAQ target user types
• Badge categories (map to PR/FAQ personas):
  • 🥾 Valley Explorer: Visit 10/25/50+ parks
  • 🚵 Trail Rider: Check MTB status, visit MTB trailheads
  • 📸 Photographer: Visit scenic overlooks and waterfalls
  • 📜 Historian: Visit historical sites and cemeteries
  • 🦅 Naturalist: Visit nature centers and preserves
  • 🎪 Event Goer: Attend/save events
  • 🗺️ Contributor: Submit content that gets approved
• Promotions: Level tiers within each badge (Bronze → Silver → Gold)
• Depends on: Get https://rootsofthevalley.com Running Live #3 (visited list) for tracking

Phase 5: Personalized Experience

10. Personalized Home for Logged-In Users

• What: When logged in, the default view shows: trail status for watchlisted trails, events this weekend at watchlisted locations, "discover something new" recommendations
• Why: Anonymous and logged-in users should have different experiences. The sidebar becomes a personal dashboard
• Depends on: Move Property Owners to Manageable System #2 (watchlist), Create Positioning, Messaging and Other Marketing Assets #4-5 (saves/likes), Add editable Drive ID fields in Settings #9 (badges)

11. "Happening This Weekend" First-Class View

• What: Dedicated view/mode showing all events happening today/this weekend, prominently accessible
• Why: PR/FAQ hammers this use case. A Saturday morning visitor should see "14 events happening today" without navigating tabs
• UX: Could be a banner on the map view, a landing page mode, or a prominent filter on the Events tab

---

Architecture Considerations

• User data storage: Want-to-visit, visited, saves, likes, badges all require per-user data tables. Design the schema to be extensible
• Authentication: Google and Facebook login already exist. These features give regular (non-admin) users a reason to use it
• Privacy: Likes are anonymous counts. Visited/watchlist data is private to the user. No public profiles unless explicitly opted in
• Moderation queue reuse: Community submissions (Add Astronomy Activity #6) should flow through the existing moderation pipeline, not a parallel system
• MCP server: Public server should be a separate process/container from the admin MCP server, with rate limiting and no write access

---

Success Metrics

• Logged-in users: Currently login is admin-only in practice. Target: regular users creating accounts
• Return visits: Weekly mailing list open rate and click-through
• Content contributed: Community submissions per week
• Exploration breadth: Average POIs visited per user (are people discovering new places?)
• MCP adoption: External agent queries per week

---

References

• PR/FAQ Document
• PR/FAQ core insight: "People experience FOMO — they know cool things are happening in parks they haven't visited, but finding out what and where requires more effort than most people will spend."
• PR/FAQ differentiation: "AllTrails serves athletes. ROTV serves the curious."
• PR/FAQ community promise: "The valley belongs to everyone. The map should too."

Phase 6: Trip Planning

12. Destination Planner (Trip Builder)

• What: Multi-stop trip builder with Google Maps handoff. Users add up to 9 waypoints, then "Start Navigation" generates a Google Maps Directions URL with origin (GPS), destination (final stop), and pipe-delimited waypoints using raw lat/long
• Why: Extends the Phase 1 directions button from single-POI to multi-stop itineraries. Makes ROTV the starting point for a day in the valley, not just a lookup tool
• UX: List/card view with "Add to Trip" buttons, drag-to-reorder, "Start Navigation" button that opens Google Maps (or Apple Maps on iOS)
• Offline support: Cache coordinates and trip data locally — many areas have 0/5 cell signal
• Badge integration: Certain destinations marked "Secret" are hidden until the user earns specific badges (Add editable Drive ID fields in Settings #9)
• Depends on: Add Automatic Themes for Holidays and Seasons #1 (directions button as foundation), Add editable Drive ID fields in Settings #9 (badge system for secret destinations)
• Original issue: "Roots of the Valley" Destination Planner #29