mirror of
https://github.com/Memo-2023/mana-monorepo.git
synced 2026-05-15 01:41:08 +02:00
Move inactive projects out of active workspace: - bauntown (community website) - maerchenzauber (AI story generation) - memoro (voice memo app) - news (news aggregation) - nutriphi (nutrition tracking) - reader (reading app) - uload (URL shortener) - wisekeep (AI wisdom extraction) Update CLAUDE.md documentation: - Add presi to active projects - Document archived projects section - Update workspace configuration Archived apps can be re-activated by moving back to apps/ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
7.2 KiB
7.2 KiB
Implementierungs-Vergleich: Module vs. HTML Cards
Zusammenfassung für Entscheidungsfindung
🎯 Die Kernfrage
Soll das Card-System komplett auf HTML/CSS umgestellt werden oder ein Hybrid-Ansatz verfolgt werden?
Option 1: Vollständige HTML/CSS Migration
Wie es funktioniert
<!-- Nutzer schreibt direkt HTML/CSS -->
<div class="my-custom-card">
<style>
.my-custom-card {
background: linear-gradient(45deg, #ff6b6b, #4ecdc4);
padding: 2rem;
border-radius: 1rem;
}
</style>
<h1>{{username}}</h1>
<p>{{bio}}</p>
</div>
✅ Vorteile
- Maximale Freiheit für kreative Nutzer
- Einfachere Datenbank (nur HTML/CSS Text speichern)
- Universell portabel (funktioniert überall)
- Keine Framework-Abhängigkeit
❌ Nachteile
- Sicherheitsrisiko (XSS, CSS-Injection)
- Keine Garantie für Responsive Design
- Schwer für Anfänger
- Performance nicht kontrollierbar
- Wartbarkeit leidet
Datenbank-Schema
CREATE TABLE cards (
id TEXT PRIMARY KEY,
user_id TEXT,
html TEXT, -- Einfacher HTML String
css TEXT, -- Einfacher CSS String
variables JSON -- Template-Variablen
);
Option 2: Beibehaltung Modulares System
Wie es funktioniert
// Nutzer konfiguriert Module
{
modules: [
{ type: 'header', props: { title: 'Titel' } },
{ type: 'content', props: { text: 'Inhalt' } }
];
}
✅ Vorteile
- Konsistente Qualität
- Automatisch responsive
- Sicher (kein Code-Injection)
- Einfach für Anfänger
- Optimale Performance
❌ Nachteile
- Begrenzte Kreativität
- Komplexere Datenbank
- Framework-abhängig
- Mehr Entwicklungsaufwand
Option 3: Hybrid-Ansatz (EMPFEHLUNG) 🏆
Die beste Lösung aus beiden Welten
interface UnifiedCard {
renderMode: 'beginner' | 'advanced' | 'expert';
// Beginner: Visual Builder
modules?: ModuleConfig[];
// Advanced: Template mit Variablen
template?: string;
// Expert: Raw HTML/CSS
customHTML?: string;
customCSS?: string;
}
Drei Stufen für verschiedene Nutzergruppen
🟢 Stufe 1: Visual Builder (80% der Nutzer)
// Einfach, sicher, schnell
{
renderMode: 'beginner',
modules: [
{ type: 'header', props: { title: 'Meine Karte' } }
]
}
🟡 Stufe 2: Template Editor (15% der Nutzer)
// Flexibler, aber noch kontrolliert { renderMode: 'advanced', template: `
<div class='card'>
<h2>{{title}}</h2>
<p>{{description}}</p>
</div>
` }
🔴 Stufe 3: Code Editor (5% der Nutzer)
// Volle Kontrolle für Power-User { renderMode: 'expert', customHTML: '
<div>Komplett custom...</div>
', customCSS: '.custom { ... }' }
📊 Entscheidungsmatrix
| Kriterium | Nur Module | Nur HTML | Hybrid |
|---|---|---|---|
| Nutzerfreundlichkeit (Anfänger) | ⭐⭐⭐⭐⭐ | ⭐ | ⭐⭐⭐⭐⭐ |
| Flexibilität (Experten) | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Sicherheit | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| Performance | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| Wartbarkeit | ⭐⭐⭐⭐⭐ | ⭐ | ⭐⭐⭐⭐ |
| Entwicklungsaufwand | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| Datenbank-Komplexität | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Zukunftssicherheit | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
🚀 Implementierungs-Roadmap für Hybrid-Ansatz
Phase 1: Vorbereitung (Woche 1)
// 1. Unified Card Interface definieren
interface UnifiedCard {
id: string;
renderMode: RenderMode;
config: ModularConfig | TemplateConfig | CustomConfig;
constraints: CardConstraints;
}
// 2. Renderer abstrahieren
class CardRenderer {
render(card: UnifiedCard): HTMLElement {
switch (card.renderMode) {
case 'beginner':
return this.renderModular(card);
case 'advanced':
return this.renderTemplate(card);
case 'expert':
return this.renderCustom(card);
}
}
}
Phase 2: HTML/CSS Renderer (Woche 2-3)
// Sicherer HTML Renderer mit Sandboxing
class SafeHTMLRenderer {
private sanitizer = new DOMPurify();
render(html: string, css: string): SafeHTML {
const safeHTML = this.sanitizer.sanitize(html);
const safeCSS = this.sanitizeCSS(css);
return this.wrapInIframe(safeHTML, safeCSS);
}
}
Phase 3: Migrations-Tools (Woche 4)
// Konverter zwischen Formaten
class CardConverter {
// Module → HTML
modulesToHTML(modules: ModuleConfig[]): string {
return modules.map((m) => this.moduleToHTML(m)).join('');
}
// HTML → Module (Best Effort)
htmlToModules(html: string): ModuleConfig[] {
// AI-unterstützte Konvertierung
return this.parseHTMLStructure(html);
}
}
Phase 4: UI Integration (Woche 5-6)
<!-- Unified Card Builder -->
<script>
let mode = 'beginner';
let card = createEmptyCard();
</script>
<div class="builder">
<!-- Mode Selector -->
<ModeSelector bind:mode />
<!-- Conditional Editors -->
{#if mode === 'beginner'}
<VisualBuilder bind:card />
{:else if mode === 'advanced'}
<TemplateEditor bind:card />
{:else}
<CodeEditor bind:card />
{/if}
<!-- Universal Preview -->
<CardPreview {card} />
</div>
💰 Kosten-Nutzen-Analyse
Entwicklungskosten
- Nur Module: 2 Wochen (bereits fertig)
- Nur HTML: 4 Wochen (Neuimplementierung)
- Hybrid: 6 Wochen (beide Systeme)
Langfristiger Nutzen
- Nur Module: Begrenzte Zielgruppe
- Nur HTML: Sicherheitsrisiken, Support-Aufwand
- Hybrid: Maximale Reichweite, zukunftssicher
🎯 Finale Empfehlung
Implementiere den Hybrid-Ansatz mit folgender Priorität:
- Behalte das modulare System als Hauptfeature
- Füge Template-Editor hinzu für fortgeschrittene Nutzer
- HTML/CSS als "Beta-Feature" für Power-User
- Schrittweise Migration basierend auf Nutzer-Feedback
Warum Hybrid?
- ✅ Keine Breaking Changes - Existierende Cards funktionieren weiter
- ✅ Progressive Enhancement - Nutzer können wachsen
- ✅ Marktdifferenzierung - Einzigartige Features für alle Nutzergruppen
- ✅ Risikominimierung - Sicherheitsprobleme nur bei Opt-in
- ✅ Lernkurve - Anfänger werden nicht überfordert
Datenbank bleibt flexibel:
-- Einheitliche Struktur für alle Modi
CREATE TABLE unified_cards (
id TEXT PRIMARY KEY,
user_id TEXT,
render_mode TEXT CHECK(render_mode IN ('beginner', 'advanced', 'expert')),
-- Für modulare Cards
modules JSON,
-- Für Template Cards
template TEXT,
template_vars JSON,
-- Für Custom HTML
custom_html TEXT,
custom_css TEXT,
-- Gemeinsam
constraints JSON,
theme_id TEXT,
created_at TIMESTAMP,
updated_at TIMESTAMP
);
🏁 Nächste Schritte
- User Research: Umfrage welche Features gewünscht sind
- Proof of Concept: HTML-Renderer mit Sandbox
- Security Audit: Externe Überprüfung
- Incremental Rollout: Erst für Premium-User
- Monitoring: Welcher Modus wird wie genutzt?