Nutzersegmente 2

[hugotiburtino]

Segment 2 – OER-Plattformbetreibende & technische Integrator:innen

(Kernsegment – Höchste Relevanz für den Design-Sprint)

Kurzbeschreibung / Rolle im System:

Dieses Segment stellt die technische Basis des EduFeed-Netzwerks dar. Plattformbetreibende und Integrator:innen sorgen dafür, dass Inhalte über das Nostr-Protokoll zugänglich, sicher und dezentral gespeichert werden. Sie profitieren von der technischen Interoperabilität, Reichweitensteigerung und Nachhaltigkeit, die EduFeed bietet, und bilden die infrastrukturelle Grundlage, auf der alle anderen Segmente aufbauen.

Rolle im EduFeed-Ökosystem

• Technische Partner, die EduFeed implementieren oder anbinden
• Zuständig für Datenübertragung und -synchronisation
• Ermöglichen Reichweite und Datenstabilität

Beispiele für Berufsgruppen

• OER-Plattformbetreiber:innen, Systemarchitekt:innen, Entwickler:innen
• Institutionelle IT-Abteilungen, Hochschulen, Bildungsnetzwerke

Motivationen / Treiber

• Interesse an offenen, interoperablen Systemen

• Effizienzsteigerung und Netzwerknutzen

• Austausch zwischen Plattformen

Ziele / Needs

• Nachhaltige Sicherung und Verfügbarkeit
• Sichtbarkeit & Reichweitensteigerung
• Einheitliche Schnittstellen & Protokolle
• Reduktion technischer Wartung

Pain Points / Probleme

• Fragmentierte Standards und Schnittstellen
• Fehlende Automatisierung in der Datenpflege
• Technische Redundanz und Mehraufwand

Technische Kompetenz

Hoch (Entwicklungs- und Architekturkenntnisse)

Design-Implikationen

• Visuelle Kommunikation von Datenflüssen & API-Strukturen
• Dokumentations-UX: klar, modular, nachvollziehbar
• UX-Sprache darf technischer sein, aber verständlich bleiben

[hugotiburtino]

Hi @BallmannUX,

1. Erstmal würde ich grundsätzlich OER-Plattformbetreibende (hier auch Hochschulen und Bildungsnetzwerke gemeint) von der Entwicklungs-Leute unterscheiden. OER-Plattformbetreibenden interessiert, was ist der Mehrwert, wenn die Daten ihrer OER-Platform über Edufeed abrufbar sind. Der Entwicklung interessiert, wie viel sie coden und lernen müssen, um deises Ziel zu erreichen. Ich glaube, wir müssten beide unterschiedlich ansprechen. Und ich bin der Meinung, Plattformbetreibenden sind diesbezüglich wichtiger.

Visuelle Kommunikation von Datenflüssen & API-Strukturen

Das würde z.B. weniger einen OER-Plattformbetreiber ansprechen.

---

Wenn wir von jetzt an nur von Systemarchitekt:innen, Entwickler:innen u.a. sprechen.

2. Was meinst du mit den Pain Points? Ist das die Pain Points, die sie bei der Anbindung mit Edufeed haben könnten? Wenn ja, dann würde ich so formulieren:

Pain Points / Probleme

• Komplizierte Umwandlungen von im OER bestehenden Daten zum Nostr-Format
• Kein ausgeprobt einfach zu deployendes Relay
• Nostr-Protokoll ist nicht so verbreitet und macht den ersten Eindrück, es ist, es viel zu viel Arbeit zu lernen

3. Zu:

Design-Implikationen

• Visuelle Kommunikation von Datenflüssen & API-Strukturen
• Dokumentations-UX: klar, modular, nachvollziehbar
• UX-Sprache darf technischer sein, aber verständlich bleiben

Das Entwicklungsteam von einer Partner-OER-Platform sollte keine Arbeit im Frontend haben. Es sollte eher entweder die Daten zu einem Relay zur Verfügung stellen oder selbst ein Relay aufbauen. Vielleicht passt besser:

• Visuelle Kommunikation von Datenflüssen
• Links zu herausragenden Dokumentationen und Bibliotheken