Roadmap evo-edu.org

Roadmap for coherent labs, curriculum support, and self-directed study.

Roadmap

Build evo-edu.org around pathways, not disconnected apps.

The next version of evo-edu.org should give teachers and self-learners a stable home for digital evolution labs, field ecology resources, scaffolded learning pathways, and project-based exploration tied to the NGSS.

LS4 + LS2 Start from evolution and ecosystem dynamics, then widen out.
K12 + self-study Support teachers, classrooms, clubs, and motivated autodidacts.
Three pillars Avida-ED labs, EcoSpecies atlas, and Didactopus-guided study.
One frame Consistent theme, navigation, expectations, and progression language.

Priority expansion order

  1. Phase 1: strengthen the current core. Clarify evo-edu.org around LS4 evolution, LS2 ecosystems, and scientific practices already supported by Avida-ED and EcoSpecies.
  2. Phase 2: add explicit learning pathways. Create K-5, middle school, high school, undergraduate-intro, and self-learner launch pages that point to the same underlying resources with different framing.
  3. Phase 3: add standards maps and lesson bundles. Tie resources to NGSS performance expectations, disciplinary core ideas, crosscutting concepts, and science and engineering practices.
  4. Phase 4: broaden into inheritance, adaptation, biodiversity, and human impact. Use EcoSpecies case materials, Avida experiments, and guided-study scaffolds to cover more of LS3, LS4, and ESS3.
  5. Phase 5: guided study and mastery support. Connect Didactopus to course packs, reading paths, review prompts, and self-directed study flows without turning it into an answer machine.

Platform roles

Avida-ED

The core lab environment for natural selection, mutation, adaptation, tradeoffs, and evidence from digital experiments.

EcoSpecies Atlas

The field-and-data side of evo-edu.org, where ecology, species life history, biodiversity, and research documentation come together.

Didactopus

A guided-study companion for autodidacts and structured review. It should support evo-edu course packs, concept maps, and reflection workflows.

Literature Explorer

A research-support tool for topic expansion, bibliography discovery, and evidence trails, built on CiteGeist rather than presented primarily as CiteGeist itself.

Platform quality and learner experience

What a bright but naive learner experiences now

The new landing pages are clearer than the older app directories, but the actual application surfaces are still inconsistent. Several published tools still rely on iframe wrappers over legacy runtimes, which means controls can remain hard to find, layout behavior can still feel nonresponsive, and the first useful action is not always obvious once the learner is inside the app.

Support-material inconsistency

Support materials are uneven across the current public platforms. Some tools have a strong public wrapper plus teacher and learner support, while others only expose a combined study guide or a curriculum page without a clearly separate teacher guide, standards page, or provenance note.

Most important structural gap

The platform catalog now feels more coherent than the platform interiors. That means the next revision cycle should focus less on adding new app cards and more on bringing the actual app runtime, guide, standards, and inquiry scaffolding up to a common public contract.

Recommended next implementation steps

  1. Create pathway pages for middle school, high school, and self-learners.
  2. Add an NGSS mapping page that links each platform to specific practices and performance expectations.
  3. Develop EcoSpecies activity sets around food webs, habitat change, biodiversity, and evidence evaluation.
  4. Use Didactopus to generate structured study packs and review paths tied to evo-edu resources and readings.
  5. Integrate Literature Explorer into teacher workflows, EcoSpecies editorial work, and advanced self-learner bibliography building.

Platform remediation plan

  1. Define a published-platform contract. Every public platform should have: a learner-facing landing page, an actual application page, a learner study guide, a teacher guide or clearly labeled teacher-use section, curriculum alignment or standards mapping, and an about/provenance note.
  2. Audit the current public platform set against that contract. Treat Allele Tracker as the strongest current reference point, then identify which published tools are still missing a separate teacher guide, standards page, provenance note, or clearly framed first-use workflow.
  3. Add role-based walkthroughs to the remediation process. Review each app as a student, casual learner, teacher, administrator, and scientist. Use those walkthroughs to surface first-task confusion, weak control visibility, missing teacher-use cues, administrative readiness gaps, model-limit overclaiming, and missing links between the app, the Notebook, and standards or curriculum support.
  4. Require fairness-and-scientific-virtues attribution review for source-derived apps. If a public route derives from or wraps earlier source material, the remediation process must carry forward attribution fairly and explicitly: original lineage, later ports, current adaptations, model limits, and what evo-edu changed versus inherited.
  5. Prioritize the app interior, not just the wrapper. For iframe-wrapped legacy runtimes such as Allele Tracker, Climate Range Shifter, and EcoBalance, revise the actual application surface so controls are conspicuous, the first task is obvious, and the layout behaves acceptably on smaller screens instead of assuming the wrapper solves the learner experience.
  6. Bring EcoSpecies into the same public contract. EcoSpecies is powerful but still feels like a separate workspace product rather than a consistent evo-edu learning platform. Align its shell, learner framing, teacher-use pathway, and curriculum support with the rest of the published app family.
  7. Standardize teacher and learner support language. Use the same naming and expectations across platforms: what this tool is for, what to try first, what concepts to watch, what evidence to record, and where teachers go next.
  8. Add responsive-design and control-visibility checks to the platform review process. A platform should not count as public-ready merely because it launches. Public-ready should also mean the controls are visible, the layout remains usable on smaller screens, and the first-run experience is legible to a learner without prior coaching.
  9. Add platform-quality checks to the roadmap and regression culture. Over time, evo-edu.org should move from “app present” toward “app ready for learners,” with explicit checks for support-page completeness, shell consistency, and public-runtime usability.

Suggested remediation order

  1. Wave A: establish the public-ready reference model. Use Allele Tracker and Digital Evolution Lab to define what a finished evo-edu platform should look like. Allele Tracker already has the strongest support-material package, while Digital Evolution Lab avoids the iframe-wrapper problem but still lacks separate teacher, standards, and provenance support.
  2. Wave B: repair the ecology runtime family. Climate Range Shifter, EcoBalance, and Life Cycle Modeler share the same learner-facing problem profile: good wrappers, weak or legacy interior runtime, and incomplete teacher/standards support.
  3. Wave C: repair the evolutionary-computation runtime family. Cumulative Selection Explorer, Network Builder, Route Optimizer, Shape Evolver, and Gene Flow Mapper should then be brought up to the same contract, with special emphasis on making the first task and controls legible for novices.
  4. Wave D: align special cases. EcoSpecies and Literature Explorer should be brought into the same public contract, but each requires a domain-specific treatment because they behave more like a workspace product or external research-support system than a compact classroom simulation.

Replacement and pattern opportunities

Shape Evolver should be treated as a replacement success path, not a generic legacy app.

The current Shape Evolver route already points to the newer Biomorphs runtime rather than the older jsbiomorph implementation. That makes it a useful exception inside the artificial-life family: the public route still needs cleanup, but the underlying replacement direction is already established.

Biomorphs can be the reference pattern for app remediation.

The newer Biomorphs package already includes responsive design, richer learner guidance, standards support, export tools, and clearer pedagogical framing. That makes it a better model for remediating older iframe-wrapped apps than the weaker legacy runtimes themselves.

Use Biomorphs-derived expectations when modernizing other apps.

When revising the ecology and artificial-life families, borrow the Biomorphs pattern: clear first task, visible controls, explicit concept targets, teacher guidance, standards support, and a runtime that does not rely on an opaque legacy UI hidden behind a generic wrapper.

Role-based walkthrough process

Why this is needed

The structural audit shows whether a public app has the expected pages. It does not show whether the first task is obvious, whether the controls are legible to a learner, whether a teacher can use the tool tomorrow, or whether a scientist or administrator will trust the framing. Role-based walkthroughs should therefore become a standard part of the remediation process.

Roles to review for every app

Each public route should be reviewed as a student, casual learner, teacher, administrator, and scientist. The review should look for UI friction, engagement gaps, appropriateness problems, overclaiming, and missing linkages between app, guides, standards, Notebook, and broader pathways.

Attribution is part of remediation, not an afterthought.

For apps that derive from specific earlier tools or source packages, the walkthrough process must also check fairness and scientific virtues in attribution: who originated the model, who ported it, what evo-edu changed, what limits remain, and where a learner or reviewer can inspect that lineage.

Seed reference case

Shape Evolver should be the first completed role-walkthrough case, and Allele Tracker should be the second. Shape Evolver shows how a stronger replacement runtime helps. Allele Tracker shows how historical depth, source lineage, and older public pages create a different but equally important remediation profile.

License and Provenance Risk

Source-derived apps need explicit license review.

The PopG notice appears to impose real distribution and revenue-related restrictions. That means source-derived public routes such as Allele Tracker should not be treated as safely settled merely because provenance is documented. Public deployment terms may require explicit confirmation or permission.

Immediate risk-reduction standard

Carry forward the full upstream notice, state clearly that the route is based on the earlier model family, and avoid implying that evo-edu independently relicensed the work. Provenance fairness and scientific virtues both require that level of explicitness.

Runtime UI principles from current remediation

Separate action controls from configuration controls.

Allele Tracker shows one useful pattern worth carrying forward: keep run, save, export, and import actions grouped separately from parameter configuration. Learners should not have to hunt through form inputs to find the next action.

Keep controls and display visible together.

Responsive redesign should not simply stack everything into a long column. The main display and the controls that immediately affect it should remain adjacent or simultaneously visible whenever possible, especially on tablets and smaller laptops.

Teach the first move before the dense interface appears.

When a runtime is still complex or partially legacy, the public app page should state the first useful experiment plainly before the learner enters the interface. This matters more than decorative wrapper polish.