OpenTrail product and UX research
A dated research set covering competitive UX, product priorities, layout direction, component contracts, release sequencing, and storage capacity.
Status and provenance
This article records six locally archived HTML research artifacts created on August 6, 2026. The set compares OpenTrail with a sampled AllTrails experience, proposes a release sequence, explores a photo-forward interface, defines implementation-ready components, and estimates long-term photo and GPS storage.
The source artifacts explicitly state that they made no application changes, deployments, pull requests, or releases. Every recommendation below remains proposed until it is reconciled with the current repository, approved, implemented, tested, released, and documented in the main OpenTrail project article.
The comparison was a dated snapshot, not continuous monitoring. AllTrails observations came from a live browse of its homepage and one sampled trail page; OpenTrail observations came from the codebase and running stack available during that research session. Scores are subjective planning aids rather than measurements or endorsements.
The research repeatedly labels OpenTrail as v0.3.0. The existing wiki's repository evidence records package manifests at 1.1.0 and release tags through v1.0.1. No proposed version number from this research should be adopted until the OpenTrail repository, tags, changelog, and deployed release are checked together. The product themes can survive this mismatch; the proposed release numbers may need remapping.
The six-part research set
| Artifact | Purpose | Output | Evidence status |
|---|---|---|---|
| 1. UX teardown | Compare discovery and trail-detail experiences. | Feature-gap matrix and sequenced product recommendations. | Dated competitive observation plus codebase review. |
| 2. Scorecard | Make relative strengths and weaknesses visible. | Eleven unweighted category scores and an overall 5.5 versus 8.2 comparison. | Author judgment; useful for prioritization, not proof. |
| 3. Roadmap | Sequence high-payoff work from depth through public launch. | Seven proposed web releases plus a parallel mobile track. | Planning artifact with an outdated or conflicting version baseline. |
| 4. Layout design | Show how the product could lead with place and emotion. | Homepage, trail mosaic, live-recording, recap, and offline concepts. | Rendered mockups; no production UI was changed. |
| 5. Component specification | Translate the visual direction into buildable contracts. | Tokens, card variants, mosaic states, responsive rules, accessibility, and handoff order. | Build-ready proposal; must be checked against current code. |
| 6. Storage estimate | Size unbounded user-photo and GPS-track growth. | Per-item assumptions, four capacity scenarios, redundancy, backup, and cloud crossover. | Order-of-magnitude planning model; prices require a fresh quote. |
UX teardown: desire before navigation
The research's central thesis is that OpenTrail's observed interface led with route geometry while the sampled competitor led with photography. A map answers where does this go?; an image first answers do I want to go? The proposal is not to remove maps, but to sequence the journey: inspire with real trail imagery, support the decision with social proof and scannable facts, then expand the route for navigation.
High-value presentation gaps
- Photo-forward trail cards and a photo-mosaic detail hero.
- Visible rating and review counts on discovery cards.
- Estimated hike time and a scannable length/gain/time/type row.
- Interactive elevation, route points of interest, trail tags, and breadcrumbs.
- Review dates, condition tags, photos, and carefully grounded summaries.
Larger product gaps
- Named collections and completed-hike history.
- GPX export, device handoff, and offline packs.
- Activity recording and historical recaps.
- Broader geographic coverage and scaled search.
- Curated collections and richer discovery filters.
The teardown also identifies photos as more than decoration: volume can signal popularity, dated images can reveal current conditions, a tour can preview wayfinding, and people in photographs can communicate belonging. Those benefits depend on real, licensed, moderated images—not generated trail scenes presented as reality.
OpenTrail's moderation-first policy protects users but slows the supply of approved photos. A photo-led interface can become an empty shell unless the product first defines safe supply, graceful zero-photo states, moderator capacity, and measurable quality thresholds.
Comparative scorecard
The source used a zero-to-ten scale where ten meant best-in-class at the time and five meant functional but unremarkable. The averages were unweighted: OpenTrail 5.5 and the sampled AllTrails experience 8.2. The research warns that imagery and social proof matter more to first impressions than a simple average reveals.
| Category | OpenTrail | Sampled competitor | Research interpretation |
|---|---|---|---|
| Imagery and photos | 2.5 | 10.0 | Photo hero, gallery volume, and photo-tour experience |
| Content coverage | 3.0 | 10.0 | Breadth of trails and regions |
| Navigation and offline | 2.5 | 9.5 | GPX, offline maps, device handoff, and 3D preview |
| Engagement and retention | 3.0 | 9.0 | Lists, completed hikes, recording, history, and recaps |
| Social proof and reviews | 4.0 | 9.5 | Visible ratings, counts, review photos, and summaries |
| Trail information depth | 6.0 | 9.5 | Stats, elevation, points of interest, tags, and estimated time |
| Motion and polish | 6.0 | 9.0 | Transitions, loading states, carousels, and preview motion |
| Discovery and search UX | 6.5 | 9.0 | Map exploration, search, and filter richness |
| Privacy and data ethics | 9.5 | 3.5 | Metadata removal, proxied geocoding, and an ad-free model |
| Values and personality | 8.5 | 5.5 | Open source, trail-buddy identity, and community positioning |
| Safety and hazards | 8.5 | 6.0 | Wildfire proximity, forecasts, and active alerts |
Where OpenTrail can remain different
The research does not recommend cloning a mature incumbent. It identifies a defensible OpenTrail position built from choices already documented in the project:
- Safety: live wildfire context, proximity warnings, weather forecasts, and active alerts.
- Privacy: EXIF/GPS stripping, server-side geocoding, minimal tracking, and deliberate data boundaries.
- Trust: moderation before publication, role-aware administration, and revocable sessions.
- Values: AGPL open source, no ads, open data, and a community rather than paywall-centered identity.
- Personality: Fern, Ace, and Ivy give the product a human voice that a purely functional map lacks.
The strategic lesson is to close the most visible experience gaps while making privacy, safety, openness, and accessibility more obvious—not trading those strengths away for superficial parity.
Proposed research roadmap
The roadmap's sequencing logic is sound even if its version labels require reconciliation: extract value from existing data first, solve photo supply before depending on imagery, add offline and retention capabilities, scale geographic coverage after the core experience is strong, then finish accessibility, delivery automation, documentation, and launch readiness.
| Research phase | Effort | Proposed outcome | Dependency or reasoning |
|---|---|---|---|
| v0.4 — Depth | S–M | Estimated time, ratings on cards, a four-part stats row, elevation profile, route points of interest, breadcrumbs, tags, and richer review context. | Mostly presentation and derivation from data the research believed was already available. |
| v0.5 — Image-forward | L | Photo supply controls, reputation tiers, photo-mosaic hero, photo-first cards, gallery/tour, and a moderated-review summary. | Resolve moderation versus photo-volume risk before depending on an image-led experience. |
| v0.6 — Take it with you | M–L | GPX export, PWA/offline packs, offline safety information, send-to-phone handoff, and an optional 3D flyover. | Treat loss of connectivity as a primary outdoor-use state. |
| v0.7 — Come back tomorrow | M | Named collections, completed-trail history, editorial lists, and optional early social activity. | Move from a one-time lookup tool toward a personal hiking record. |
| v0.8 — Everywhere | L | Regional-to-national import, scaled search, cache tuning, deduplication, and data-quality work. | Scale coverage only after the individual trail experience is worth scaling. |
| v0.9 — Polish | M | Motion, accessibility audit, CI smoke/lint/security checks, and contributor documentation. | Make operational and accessibility quality part of release evidence. |
| v1.0 — Public launch | M | Public story, contributor onboarding, versioned API commitment, launch operations, documentation, and general availability. | A launch is a compatibility and operating promise, not only a public URL. |
Parallel mobile track
Live GPS recording, running statistics, offline navigation, and rich trip recaps were treated as a separate Expo/React Native track so mobile-native work would not block the web roadmap. The research suggests beginning after offline foundations exist. Before adoption, this needs an explicit data-sync model, battery and background-location testing, consent and retention rules, emergency-state UX, and a threat model for location history.
Proposed homepage and trail layout
The layout connects each experience to a roadmap dependency instead of pretending it ships in one redesign: photo-first surfaces require safe photo supply; offline demonstrations require reliable pack generation; history requires completion models; and recording belongs to the mobile track.
Build-ready component specification
Design foundations
The specification defines light/dark semantic tokens for brand green, warm accent, rating gold, danger red, text, muted text, surfaces, panels, and outlines. It separates semantic meaning from decoration: rating gold indicates quality, danger red indicates stop or risk, and brand green must not substitute for either. Spacing follows an eight-based scale, motion has fast/base/slow durations, and nonessential motion respects prefers-reduced-motion.
Trail card contract
- Four proposed variants: horizontal strip, discovery grid, featured overlay, and compact row.
- The first approved photo is the cover; a no-photo state uses an honest placeholder.
- The save control uses a minimum 44-pixel target, keyboard focus, and
aria-pressed. - The metadata row exposes rating, difficulty, distance, and estimated time.
- The research believed only estimated time was new to the summary payload; current code must verify that assumption.
Photo mosaic contract
Every cell is a real button with a visible focus state and useful alternative text. Images remain moderated WebP uploads with metadata removed. The map tile should use the established MapLibre-compatible/open-data path so the visual redesign does not reopen licensing decisions.
Recommended handoff order
- Reconcile tokens with the current theme and confirm contrast in both modes.
- Derive estimated time and add it to the current trail contract without unnecessary schema work.
- Build and test the reusable trail-card variants and empty/loading states.
- Build the mosaic fallback ladder independently of the future photo-volume system.
- Add the stats row, then the keyboard-accessible lightbox/photo tour.
- Verify responsive, reduced-motion, screen-reader, image-licensing, and moderation behavior before release.
Photo and GPS storage capacity estimate
The storage model assumes an optimized photo costs about 0.5 MB (WebP up to 2048 pixels plus a thumbnail) and a compressed recorded hike about 0.1 MB. It assumes original uploads are discarded after safe re-encoding. Under those assumptions, photos—not GPS tracks—drive most growth.
| Scenario | Trails | Photos | Recorded hikes | Estimated total |
|---|---|---|---|---|
| Seed Oregon | 20,000 | 160,000 | 75,000 | about 90 GB |
| Active Oregon | 20,000 | 800,000 | 1,000,000 | about 0.5 TB |
| Pacific Northwest | 100,000 | 4,000,000 | 3,000,000 | about 2.3 TB |
| National mature | 400,000 | 24,000,000 | 20,000,000 | about 14 TB |
Research recommendation
- Begin with two 4 TB drives mirrored or a two-bay NAS.
- Keep a separate offsite object-storage backup.
- Move toward a larger NAS and tier cold media as usage approaches regional scale.
- Re-evaluate cloud object storage around the multi-terabyte crossover.
Controls and caveats
- A mirror protects against one drive failure; it is not a backup.
- Fire, theft, corruption, ransomware, and accidental deletion require offsite recovery.
- Keeping originals could multiply photo storage by roughly eight to twelve.
- Offline map tiles are mostly regenerable and belong in a different backup class.
The quantities are order-of-magnitude estimates and the source's vendor prices are time-sensitive. Before purchasing hardware or cloud capacity, measure actual upload distributions, retention, replication, restore time, egress, monitoring, and operating cost. Test restoration; do not count an untested backup as recovery.
Decision register and security questions
| Decision | Evidence needed before adoption | Primary risk |
|---|---|---|
| Photo-first versus map-first default | Usability tests, conversion measures, zero-photo coverage, and map-task completion. | Improving inspiration while making navigation or sparse trails worse. |
| Automated photo pre-screening | Dataset, thresholds, false-negative/positive rates, appeal path, audit log, and moderator fallback. | Unsafe media publishing or trusted contributors being treated inconsistently. |
| AI review summary | Grounding solely in approved reviews, attribution, evaluation set, update triggers, and visible uncertainty. | Invented conditions, unsafe advice, bias, or stale trail information. |
| Offline packs and GPS history | Consent, encryption, retention, deletion, sync conflicts, device loss, and emergency limitations. | Highly sensitive location history exposure. |
| Regional/national expansion | Importer capacity, licensing, deduplication, moderation load, search performance, and operating cost. | Scaling low-quality or unmaintainable data. |
| Storage platform | Measured growth, failure domains, restore tests, lifecycle policy, encryption, and total cost. | Permanent loss of unregenerable user media or tracks. |
What I learned from the research
- Research must distinguish observation, judgment, proposal, implementation, and verified release.
- A product roadmap is stronger when every visual idea has a data, security, accessibility, and operational dependency.
- Competitive research should reveal where to differentiate, not create a feature-for-feature clone.
- Photo-forward design is a system problem involving supply, moderation, licensing, storage, empty states, and performance—not just a larger image.
- Location and trail-condition features require stronger privacy and accuracy controls because mistakes can affect real-world safety.
- Capacity planning begins with per-item assumptions, measures actual growth, separates regenerable from irreplaceable data, and designs restore before scale.
- Version labels in planning artifacts must be reconciled with repository and deployment evidence before they become a release plan.
If any proposal from this research enters an OpenTrail preflight, link back to this page and record the selected scope, rejected alternatives, threat model, test plan, migration, and rollback. Postflight must update the main project article with what actually shipped and what the evidence changed.