DEV Community: Anthony Wright

Building Role-Based Student, Teacher, and Admin Experiences in EchoEd

Anthony Wright — Mon, 13 Jul 2026 13:02:28 +0000

A role-based product should involve more than hiding navigation links.

Students, teachers, and platform administrators have different goals, data needs, privacy constraints, and consequences attached to their actions. EchoEd’s recent UI/UX work separates these roles into three
canonical product areas:

/learn for students
/teach for teachers
/admin for platform administrators

The attached demo videos show each experience in its current form.

Student Learn

The Student experience prioritizes continuation over navigation complexity.

The /learn home composes existing course, progress, badge, certificate, and learner-product APIs to show:

The next governed learning action
Current courses and progress
Available learning
Progress summaries
Badges and certificates

Course overviews use a reusable curriculum component for units and lessons. Lesson entry still goes through the existing start-course and progress APIs, so the UI cannot bypass backend sequencing rules.

Final assessment submissions use a shared confirmation dialog. Lesson completion exposes saving and failure states rather than optimistically assuming persistence.

No backend contracts were changed for the Student phase.

Teacher Teach

The Teacher experience introduces a canonical route family:

/teach
/teach/classes
/teach/classes/:id
/teach/curriculum
/teach/courses/:courseId/preview
/teach/assignments
/teach/learners/:learnerId

The Teacher home focuses on classes, learner progress, and curriculum. Class detail composes existing section APIs into overview, roster, assignment, progress, and discussion views.

Learner detail is scoped through class-roster context. Assignment creation uses confirmation and preserves form values after API failures.

The UI does not expose persistent feedback, manual review, or destructive discussion moderation because those workflows do not yet have sufficiently scoped backend contracts.

Platform Admin

The Admin experience uses canonical routes for overview, users, organizations, courses, badges, and reports.

Important implementation decisions include:

User lists omit unnecessary fields.
Role mutations wait for API confirmation before updating the UI.
Self-role changes and self-deletion are blocked in the interface.
Destructive actions use exact consequence language.
Organization visibility remains constrained by current membership-scoped APIs.
Course oversight does not grant Content Studio authoring.
Super Admin capabilities are based on verified authorization, not role-name assumptions.
Unsupported moderation and lifecycle controls remain absent.

During seeded browser testing, the user-detail flow exposed a backend issue: FastAPI accepted the user ID as a string while SQLAlchemy compared it with a UUID column.

The repair typed detail and update parameters as uuid.UUID. We also moved the static /api/users/students route before /api/users/{user_id} so the dynamic route could not shadow it.

Regression tests now cover both behaviors.

Shared UX and Accessibility

All three areas reuse the same production foundations:

Semantic design tokens
Role-aware shell navigation
Route guards
Shared loading and state components
Confirmation dialogs with focus trapping and restoration
Keyboard-operable controls
Visible focus indicators
Reduced-motion behavior
Semantic desktop tables
Stacked mobile record layouts
Legacy deep-link compatibility

The frontend improves presentation and workflow clarity, but backend authorization remains authoritative.

Current Verification

Frontend unit tests: 245 passing
Backend tests: 224 passing
Seeded Playwright scenarios: 3 passing
Production build: passing
Strict OpenSpec validation: passing

The Playwright suite currently covers the seeded Student workflow, the Platform Admin workflow, and rejection of an unauthorized Student deep link into Admin.

Known Gaps

Several workflows need stronger backend contracts before the UI can safely support them:

Persistent teacher feedback
Scoped teacher review
Authenticated discussion moderation
Platform-wide organization oversight
Account suspension and restoration
Administrative audit events
Badge lifecycle management
Explicit Super Admin permission inheritance
Privacy-minimized Admin user response schemas

These are documented gaps, not frontend placeholders.

Community Review

I would value feedback from people working across education and software:

Do the boundaries between Learn, Teach, and Admin match real responsibilities?
Which Teacher information should be visible at class level versus learner level?
What information should a platform administrator never see in a broad user list?
Which workflows should receive deeper screen-reader and keyboard testing?
Which backend gap would you prioritize before expanding the next UI phase?

The Student, Teacher, and Platform Admin production phases are complete for EchoEd’s currently supported APIs.

The full UI/UX overhaul is still underway. Content Studio, organization-admin self-service, Community, parent, and viewer experiences remain outside these completed phases.

Building Open-Source Education Infrastructure for African History and the African Diaspora

Anthony Wright — Fri, 10 Jul 2026 14:25:10 +0000

When people hear "education platform," they usually think about another Learning Management System.

EchoEd isn't trying to become another LMS.

It's an attempt to build open-source educational infrastructure centered on teaching African history and the histories of the African diaspora—built transparently, collaboratively, and alongside the communities it hopes to serve.

Today, I'm opening EchoEd for early community review, and I wanted to share why I'm building it, what exists today, and where I'd love help from educators and developers.

Why EchoEd Exists

History shapes identity.

It influences how we see ourselves, how we understand the world, and how future generations understand the people who came before them.

While there are many excellent educators and historians doing incredible work, access to high-quality, culturally grounded educational resources is still uneven. Many schools, homeschool families, and community organizations are looking for engaging, trustworthy ways to teach African history and the histories of the African diaspora.

I believe open source can help.

Open-source software has transformed how we build technology. It enables collaboration across organizations, countries, and backgrounds. It allows communities to improve systems together instead of relying on a single vendor or institution.

I believe educational infrastructure deserves the same approach.

Instead of building behind closed doors and asking educators to adapt later, I want EchoEd to be shaped by educators, historians, developers, accessibility advocates, and community organizations from the beginning.

Because trust should come before scale.

What Exists Today

EchoEd is still early, but it's no longer just an idea.

Today the project includes a working K–5 demonstration with:

Student learning experiences
Teacher workflows
Administrative experiences
Public documentation
Contributor onboarding documentation
Open-source contribution guidance

The goal wasn't to build every feature before inviting people in.

The goal was to build enough that meaningful conversations could begin.

What Phase 1 Prepared

Before inviting contributors, I wanted to make sure the project felt welcoming and transparent.

Phase 1 focused on preparing EchoEd for open-source collaboration rather than adding new product features.

That work included:

A significantly improved README
Contributor documentation
A Code of Conduct
Architecture documentation
Security guidance
Public demo documentation
Community trust documentation
Outreach readiness guidance
GitHub issue templates
Pull request templates
A public roadmap

These aren't the most exciting features to build.

But they're some of the most important if you want people to feel confident contributing to a project.

Good open-source communities don't happen by accident. They require intentional documentation, clear expectations, and respectful collaboration.

What Phase 2 Needs

Now the focus shifts from preparation to learning.

EchoEd doesn't need hundreds of contributors tomorrow.

It needs thoughtful feedback from people with different expertise.

Right now, the project would benefit most from:

Educator feedback

I'd love educators to walk through a learning experience and answer questions like:

Does this feel intuitive?
Would students understand the flow?
What's missing?
What classroom realities aren't being considered?

Developer contributors

There are opportunities across the stack, including:

Documentation improvements
Frontend development
Backend enhancements
Testing
Demo reliability
Accessibility improvements
Developer experience

Whether you've contributed to open source for years or you're looking for your first contribution, there's room to help.

Accessibility review

Educational software should be usable by everyone.

Improving keyboard navigation, screen reader support, semantic HTML, color contrast, and overall usability is an area where community expertise can make a real difference.

Historical review

Perhaps the most important area of all.

I'm looking for historians, educators, and community members who can help strengthen:

historical framing
source quality
representation
accuracy
balance of perspectives

Technology can accelerate learning.

But it should never replace careful historical scholarship.

How Developers Can Help

Not every contribution requires writing thousands of lines of code.

You could help by:

Improving documentation
Fixing UI issues
Building frontend features
Improving backend services
Writing tests
Improving demo reliability
Reviewing accessibility
Improving developer onboarding
Refining the architecture

Some of the highest-impact contributions to open source aren't glamorous—they simply make it easier for the next person to contribute.

How Educators Can Help

If you're an educator, I'm not asking you to volunteer countless hours.

Even reviewing one lesson or one learner journey can provide insights that fundamentally improve the project.

Helpful feedback might include:

Classroom usability
Age appropriateness
Instructional flow
Historical framing
Source recommendations
Topics that deserve greater attention

Your expertise is valuable, and I want EchoEd to reflect that by listening first.

Looking Ahead

This project has no marketing budget.

There isn't a large team behind it.

Right now, EchoEd is growing through conversations, thoughtful feedback, and people who believe education can be built more openly.

My hope is that over time, EchoEd becomes more than a software project.

I hope it becomes a community of educators, historians, developers, students, and organizations working together to expand access to meaningful, evidence-based learning about African history and the histories of the African diaspora.

If You're Interested

If any part of this resonates with you, I'd love for you to get involved in whatever way feels appropriate.

You can:

Explore the demo
Read through the documentation
Open a GitHub issue
Suggest improvements
Contribute code
Review historical framing
Share the project with someone who might have helpful expertise

Every thoughtful conversation makes the project stronger.

Because building educational technology isn't just about writing software.

It's about building trust.

And I believe the best way to build trust is to build together.