Vergleichs- und Matrix-System

Was macht Vergleichs- und Matrix-System?

Zweck

Das Vergleichs- und Matrix-System bietet eine Methodik zur Gestaltung detaillierter Entdeckungs- und Bewertungsoberflächen. Während pricing-table-ui-system hochrangige Tarifstufen und data-table-ui-system große Datensätze verwaltet, konzentriert sich dieses System auf den attributdichten Vergleich weniger spezifischer Elemente (normalerweise 2–5). Es stellt sicher, dass Benutzer komplexe Produkte oder Dienstleistungen über Dutzende von Dimensionen hinweg bewerten können, ohne die Orientierung zu verlieren, von Daten überwältigt zu werden oder mit unresponsiven Layouts zu kämpfen.

Anwendungsfälle

• E-Commerce-Produktvergleich: Vergleich technischer Spezifikationen für Elektronik, Haushaltsgeräte oder Fahrzeuge.
• SaaS-Funktionsmatrizen: Detaillierte Aufschlüsselung der Plattformfähigkeiten über die hochrangigen Preiskarten hinaus.
• Dienstleistungsvergleich: Bewertung verschiedener Versicherungspläne, Reisepakete oder Bildungskurse.
• Interne Werkzeuge: Gegenüberstellung verschiedener Systemversionen oder -konfigurationen.

Wann NICHT verwenden

• Hochrangige Preisgestaltung: Verwenden Sie für einfache 3-stufige Zusammenfassungen pricing-table-ui-system.
• Erkundung großer Datensätze: Wenn der Benutzer Hunderte von Elementen sortieren und filtern muss, verwenden Sie data-table-ui-system.
• Details zu einzelnen Elementen: Verwenden Sie article-layout-system oder card-ui-system für einzelne Produktseiten.
• Linearer Fortschritt: Verwenden Sie für schrittweise Abläufe step-progress-system.

Eingaben

1. Vergleichsset: Die 2–5 zur Bewertung ausgewählten Elemente.
2. Attribut-Taxonomie: Eine kategorisierte Liste aller zu vergleichenden Funktionen, Spezifikationen und Datenpunkte.
3. Datentypen: Eine Zuordnung von Attributen zu UI-Typen (z. B. Boolean/Häkchen, numerisch, Bewertung, Textbeschreibung).
4. Auswahlkontext: Handelt es sich um eine dauerhafte Seite oder um ein temporäres Overlay, das von einer Produktlistenseite ausgelöst wird?

Ausgaben

1. Matrix-Anatomie-Spezifikation: Definitionen für Zeilenköpfe (Attribute), Spaltenköpfe (Elemente) und Datenzellen.
2. Kategorisierungs-Framework: Regeln für die Gruppierung von Attributen in logische Abschnitte mit zusammenklappbaren Überschriften.
3. Plan für sticky Navigation: Verhaltensregeln zur Aufrechterhaltung des Kontexts während des vertikalen und horizontalen Scrollens.
4. Responsive Übergangskarte: Eine Strategie zur Anpassung der Matrix an Mobilgeräte (z. B. Elementwechsel vs. vertikales Stapeln).

Arbeitsablauf

1. Strukturierung des Raster-Frameworks

Definieren Sie die Hauptachsen der Matrix:

• Spalten: Repräsentieren die zu vergleichenden Elemente.
• Zeilen: Repräsentieren die Attribute oder Funktionen.
• Führende Spalte: Die erste Spalte links enthält die Attributbezeichnungen/-überschriften.

2. Attribute kategorisieren und gruppieren

Verhindern Sie „Vergleichsermüdung“, indem Sie Zeilen in logische Cluster organisieren:

• Abschnitte: Gruppieren Sie verwandte Attribute (z. B. „Leistung“, „Konnektivität“, „Garantie“).
• Zusammenklappbarkeit: Ermöglichen Sie Benutzern das Ein- und Ausklappen von Abschnitten, um sich auf bestimmte Kriterien zu konzentrieren.
• Visuelle Unterscheidung: Verwenden Sie dezente Hintergrundverschiebungen oder Rahmen, um Abschnitte zu trennen.

3. Datenvisualisierung standardisieren

Wenden Sie eine konsistente visuelle Sprache auf verschiedene Datentypen an:

• Booleans: Verwenden Sie kontrastreiche Häkchen (✓) für Vorhandensein und einen Bindestrich (—) oder einen leeren Zustand für Nichtvorhandensein.
• Bewertungen: Verwenden Sie konsistente Symbolskalen (z. B. 5 Sterne).
• Nuancenreicher Text: Verwenden Sie eine kleinere, lesbare Schriftgröße für Beschreibungen und achten Sie auf die Zeilenlänge innerhalb der Zelle.
• Hervorhebungen: Heben Sie Zellen visuell hervor, in denen ein Element andere deutlich übertrifft (verwenden Sie dies mit Vorsicht, um Neutralität zu wahren).

4. Sticky-Kontext implementieren (Wegweiser)

Stellen Sie sicher, dass der Benutzer nie den Überblick verliert:

• Sticky-Spaltenüberschriften: Halten Sie die Elementnamen und Bilder am oberen Rand des Viewports sichtbar, während der Benutzer durch die Zeilen scrollt.
• Sticky-Zeilenüberschriften: Halten Sie bei breiten Matrizen auf dem Desktop die Attributbezeichnungen links sichtbar, während der Benutzer horizontal scrollt.

5. Mobile Anpassung planen

Matrizen sind von Natur aus horizontal; passen Sie sie für vertikale Bildschirme an:

• Das „Selector“-Muster: Zeigen Sie die Attributliste und 1–2 Elemente gleichzeitig an und verwenden Sie ein Dropdown oder eine Wischinteraktion, um die sichtbaren Elemente zu wechseln.
• Das „Vertical Card“-Muster: Wandeln Sie die Matrix in eine Abfolge von Karten um, wobei die Attributbezeichnungen für jede Karte wiederholt werden (nur für sehr einfache Vergleiche empfohlen).

Entscheidungsregeln

• Die Regel der Fünf: Begrenzen Sie die maximale Anzahl von Elementen in einer Side-by-Side-Matrix auf dem Desktop auf 5, um horizontale Überlastung zu vermeiden.
• Attributrelevanz: Nehmen Sie nur Attribute auf, die sich zwischen mindestens zwei Elementen im Set unterscheiden. Wenn jedes Element denselben Wert hat, sollten Sie diese Informationen in einen gemeinsamen Abschnitt „Allgemeine Funktionen“ verschieben.
• Prominenz der Überschriften: Elementüberschriften (Spalte 1, 2 usw.) sollten ein kleines Bild des Produkts enthalten, um eine sofortige visuelle Wiedererkennung zu ermöglichen.
• Hover-Zustände für Zeilen: Verwenden Sie einen deutlichen Hover-Hintergrund für die gesamte Zeile, um das Auge beim Verfolgen über Spalten hinweg zu unterstützen.

Einschränkungen

• Barrierefreiheit: Zeilenköpfe müssen mit scope="row" und scope="col" korrekt mit Zellen verknüpft werden. Stellen Sie einen hohen Kontrast für Häkchen und Symbole sicher. Sticky-Spalten-/Zeilenüberschriften dürfen die Tastaturfokus-Anzeige von Zellen oder darunter liegenden Steuerelementen nicht verdecken (WCAG 2.2 SC 2.4.11). Jedes Elementwechsler- oder Dropdown-Steuerelement auf Mobilgeräten muss die Mindestzielgröße von 24x24px erfüllen (SC 2.5.8).
• Responsivität: Horizontales Scrollen muss beabsichtigt sein (z. B. innerhalb eines Containers) und darf das globale Seitenlayout nicht beeinträchtigen.
• Visuelles Gewicht: Die „führende Spalte“ (Attribute) sollte eine leicht abweichende visuelle Behandlung erhalten (z. B. hellgrauer Hintergrund oder fette Schrift), um sie von den Daten zu unterscheiden.

Häufige Fehlermuster

• Das „Verlorene Überschrift“-Problem: Langes Scrollen durch eine Matrix und Vergessen, welches Element welches ist.
• Attributüberladung: Anzeige von 50+ Zeilen ohne Kategorisierung, sodass es unmöglich wird, bestimmte Informationen zu finden.
• Mobile Kompression: Der Versuch, 4 Spalten auf einem mobilen Bildschirm unterzubringen, macht den Text unlesbar.
• Mehrdeutige Symbole: Verwendung benutzerdefinierter Symbole für „Ja/Nein“, die Benutzer nicht sofort verstehen.
• Inkonsistente Ausrichtung: Mischen von zentrierten Symbolen mit linksbündigem Text in derselben Spalte.

Validierungskriterien

• Elementüberschriften bleiben während des vertikalen Scrollens am oberen Rand des Viewports fixiert (sticky).
• Attribute sind in logische, zusammenklappbare Abschnitte gruppiert.
• Datentypen (Boolean, Bewertung, Text) verwenden eine konsistente visuelle Sprache.
• Die „führende Spalte“ unterscheidet sich visuell von den Datenspalten.
• Die mobile Ansicht bietet einen klaren Mechanismus zum Vergleichen von Elementen (z. B. Elementwechsel).
• Hover-Zustände für Zeilen sind implementiert, um die horizontale Verfolgung zu unterstützen.
• Alle Symbole und Texte erfüllen die WCAG-AA-Kontrastanforderungen (4,5:1).
• Sticky-Überschriften verdecken keine Fokus-Anzeigen auf Zellen oder Steuerelementen (WCAG 2.2 SC 2.4.11).
• Mobile Elementwechsler-Steuerelemente erfüllen die Mindestzielgröße von 24x24px (WCAG 2.2 SC 2.5.8).