Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Usability, User Experience und
Barrierefreiheit“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/usability-barrierefreiheit
- https://oer-informatik.de/wireframe-tools
- Stilbeispiel: https://oer-informatik.de/usability-barrierefreiheit-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Usability
- User Experience
- Barrierefreiheit
- DIN EN ISO 9241-110
- DIN EN ISO 9241-11
- WCAG
- Kontrast
- Screenreader
- Usability-Test
- Bedienelemente

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

4 × 1,5 Punkte (Merkmal 0,5 Punkte, Begründung mit Bezug 1 Punkt), z. B.:

Aus den Bewertungen abgeleitet (Usability):

• Robustheit und verständliches Feedback (Tobias): Ein Code wie „Fehler 0x17“ sagt nicht, was falsch ist; dass danach alle Eingaben verschwinden, macht aus einem kleinen Fehler einen Abbruch. Gute Usability heißt: Fehler werden am Feld erklärt, Eingaben bleiben erhalten.

• Lesbarkeit und Selbstbeschreibungsfähigkeit (Rainer): Kleine graue Schrift und fehlende Kennzeichnung der Pflichtfelder verhindern, dass er weiß, was zu tun ist. Gute Usability heißt: ausreichende Schriftgröße und Kontraste, dauerhaft sichtbare Beschriftungen, Pflichtfelder markiert.

• Effizienz: Tobias will „vor der Frühschicht“ schnell etwas anlegen; dreimaliges Neueingeben kostet ihn die Zeit, die er nicht hat.

Ergänzt (User Experience vor und nach der Nutzung):

• Vertrauen und Sicherheit: Treffpunkte sind öffentlich, Profile und Bewertungen sind sichtbar, die Datenschutzhinweise sind verständlich – man traut sich, Fremde zu treffen.

• Erleben nach dem Treffen: Erinnerung vor dem Termin, gelungene Aktivität, Möglichkeit zur Bewertung; man empfiehlt die App weiter und kommt wieder.

• Erster Eindruck: Store-Eintrag, Bewertungen und Einstieg in die App wecken Erwartungen; eine Reihe Ein-Stern-Bewertungen schreckt neue Nutzende schon vor dem Download ab.

Zuordnung 6 × 0,5 Punkte, Zusammenhang 1 Punkt:

• UX-Design: 1, 3, 5 – Analyse der Nutzenden, ihrer Ziele und des gesamten Erlebens vor, während und nach der Nutzung.

• UI-Design: 2, 4, 6 – Gestaltung der sichtbaren Oberfläche: Layout, Bedienelemente, Farben, Schriften, Symbole.

• Zusammenhang: UI-Design ist ein Teil des UX-Designs; die Oberfläche setzt um, was die UX-Analyse über Nutzende und ihre Ziele herausgefunden hat.

• Erläuterung (2 Punkte): „Benutzerfreundlich“ ist subjektiv und nicht messbar. Bei der Abnahme kann niemand eindeutig entscheiden, ob die Anforderung erfüllt ist; Auftraggeberin und Entwicklungsteam können darunter Verschiedenes verstehen. Usability hängt außerdem vom Nutzungskontext ab (wer, wofür, unter welchen Bedingungen), der in der Formulierung fehlt.

• Messbare Formulierung (2 Punkte), z. B.: „Registrierte Nutzende ohne Vorerfahrung mit der Funktion können auf dem Smartphone innerhalb von drei Minuten ohne Hilfe eine Aktivität mit Titel, Kategorie, Datum, Uhrzeit, Treffpunkt, Teilnehmendenzahl und Mindestalter veröffentlichen. In einem Usability-Test mit acht Personen gelingt das mindestens sieben Personen; die durchschnittliche Bewertung im SUS-Fragebogen liegt bei mindestens 70 von 100.“

Ursachen 2 × 1,5 Punkte, weitere Schwachstellen 2 × 2 Punkte (Schwachstelle 1 Punkt, Folge 1 Punkt), z. B.:

Ursachen der Beschwerden:

• Tobias („Fehler 0x17“, alles weg): Die Fehlermeldung steht oben ohne Bezug zum Feld und ohne Hinweis zur Behebung; Datum, Uhrzeit und Mindestalter sind Freitextfelder, in denen falsche Formate vorprogrammiert sind.

• Rainer (Schrift winzig und grau): Hellgraue, kleine Schrift mit geringem Kontrast; die Felder haben nur Platzhaltertext, Pflichtfelder sind nicht gekennzeichnet.

Weitere Schwachstellen:

• Hierarchie der Schaltflächen vertauscht: „Abbrechen“ ist groß und signalrot an der Stelle der Hauptaktion, „Event erzeugen“ klein und blass. Folge: Nutzende brechen versehentlich ab und verlieren ihre Eingaben.

• Treffpunkt als freie Adresse: Die App kennt öffentliche Treffpunkte, trotzdem muss man tippen. Folge: Aufwand, Tippfehler und Wohnadressen als Treffpunkt.

• Kategorie nur über Farbpunkte: Die Bedeutung ist nicht erkennbar und für Menschen mit Farbsehschwäche nicht unterscheidbar. Folge: falsche Kategorie, Aktivität wird nicht gefunden.

• Werbebanner mitten im Formular: unterbricht die Aufgabe und schiebt die Schaltflächen nach unten.

• Uneinheitliche Begriffe: „Aktivität anlegen“ im Titel, „Event erzeugen“ auf der Schaltfläche. Folge: Unsicherheit, ob man an der richtigen Stelle ist.

• Hilfe-Link öffnet ein PDF in neuem Fenster und führt aus der App heraus; auf dem Smartphone findet man schwer zurück.

4 × 2 Punkte (Prinzip 1 Punkt, Verbesserung 1 Punkt):

Bei der dritten Zeile ist auch „Steuerbarkeit“ vertretbar, wenn begründet wird, dass Tobias den Ablauf nicht wie beabsichtigt steuern konnte.

Beispielskizze:

Bewertungsvorschlag (8 Punkte):

• Titelzeile mit einheitlichem Begriff und Zurück-Navigation, kein Werbebanner (1 Punkt)

• dauerhaft sichtbare Beschriftungen, Pflichtfelder gekennzeichnet (1 Punkt)

• geeignete Eingabeelemente: Kategorie als Auswahlliste mit Text, Datumsauswahl, Uhrzeit, Teilnehmende als Bereich oder Zahlenwähler, Mindestalter als Auswahl 16+/18+ (2 Punkte)

• Treffpunkt aus öffentlichen Treffpunkten wählen, mit Filter „nur barrierefreie Treffpunkte“ (1 Punkt)

• Fehlermeldung verständlich am betroffenen Feld (1 Punkt)

• klare Hierarchie: Hauptaktion „Aktivität veröffentlichen“ groß und auffällig, Nebenaktionen („Als Entwurf speichern“, „Abbrechen“) zurückhaltend (1 Punkt)

• ausreichend große Schrift und Kontraste, bündige Ausrichtung im Raster (1 Punkt)

Situation 1 und 2 je 2 Punkte (Methode und Vorgehen 1 Punkt, Begründung 1 Punkt), Situation 3 3 Punkte (Methode und Vorgehen 1 Punkt, Begründung 1 Punkt, Datenschutz 1 Punkt), z. B.:

1. Papierprototyp-Test oder Cognitive Walkthrough: Zwei, drei Personen aus dem Team oder dem Bekanntenkreis gehen die Skizzen mit einer Aufgabe („Lege eine Laufgruppe für Samstag an“) durch; bei jedem Schritt wird gefragt, ob klar ist, was zu tun ist. Alternativ eine heuristische Evaluation anhand der Interaktionsprinzipien. Begründung: schnell, billig, ohne Programmierung; Änderungen an Skizzen kosten fast nichts.

2. Usability-Test mit lautem Denken: Fünf bis acht Testpersonen, die zu den Personas passen, erledigen typische Aufgaben am Prototyp und sprechen aus, was sie denken; die Testleitung beobachtet, hilft nicht und notiert Stellen, Dauer und Erfolg. Ergänzend ein SUS-Fragebogen oder kurzes Interview. Begründung: Nur Beobachtung zeigt, wo und warum jemand stockt; Eye-Tracking wäre möglich, ist aber aufwendig.

3. Auswertung von Nutzungsdaten bzw. A/B-Test: Es wird gezählt, wie viele Personen das Formular öffnen und wie viele es abschließen, und an welchem Feld abgebrochen wird; Vergleich mit den Zahlen vor der Umstellung oder zwei Varianten im Wechsel. Begründung: Nur so lässt sich die Abbruchquote im echten Betrieb mit vielen Nutzenden messen. Datenschutz: Auswertung pseudonymisiert bzw. zusammengefasst, nur die nötigen Ereignisse speichern (Datenminimierung), für nicht notwendige Analyse-Techniken auf dem Endgerät eine Einwilligung einholen (§ 25 TDDDG, DSGVO), die Datenschutzbeauftragte Dr. Marta Kowalczyk einbinden; wegen der 16- und 17-jährigen Nutzenden keine Profilbildung.

Stellungnahme mit Begründung, 3 Punkte, z. B.:

Dem Vorschlag ist nicht zuzustimmen. Usability sollte früh und wiederholt getestet werden (menschzentrierte Gestaltung nach DIN EN ISO 9241-210: verstehen, entwerfen, evaluieren, verbessern). Mängel, die schon im Mockup erkannt werden, lassen sich mit geringem Aufwand beheben; nach der Programmierung sind Änderungen deutlich teurer und verzögern die Veröffentlichung. Ein einziger Test am Ende zeigt zudem nur noch Probleme, aber es bleibt kaum Zeit, sie zu lösen. Sinnvoll sind kleine Tests mit wenigen Personen nach jedem Entwurfsschritt und ein abschließender Test vor der Veröffentlichung.

Bedingungen 3 × 1 Punkt, Stellungnahme 1 Punkt, rechtliche Begründung 2 Punkte, weitere Gruppen 2 Punkte, z. B.:

• in der allgemein üblichen Weise: Lukas bucht seine Mitfahrt in derselben App wie alle anderen, nicht über eine Sonderlösung wie eine E-Mail an Thomas Becker oder eine eigene „Blindenversion“.

• ohne besondere Erschwernis: Er braucht dafür nicht deutlich mehr Zeit oder Mühe, etwa weil sich jede Schaltfläche erst nach langem Suchen per Screenreader findet.

• grundsätzlich ohne fremde Hilfe: Er muss niemanden bitten, für ihn eine Fahrt anzufragen oder ihm vorzulesen, welche Plätze frei sind. Hilfsmittel wie Screenreader und Braillezeile sind dabei erlaubt – sie sind seine übliche Art, Software zu nutzen.

• Stellungnahme: Der Aussage ist nicht zuzustimmen; Barrierefreiheit muss von Anfang an eingeplant werden.

• Rechtlich: Das RRB ist als staatliche Schule eine öffentliche Stelle. Für ihre Websites und mobilen Anwendungen gelten in NRW das BGG NRW und die BITV NRW; technischer Maßstab ist die EN 301 549 bzw. die WCAG auf Stufe AA. Die Schule muss eine Erklärung zur Barrierefreiheit mit Feedback-Möglichkeit veröffentlichen. Bliebe Lukas ausgeschlossen, würde er benachteiligt.

• Weitere Gruppen: künftige Schüler*innen und Lehrkräfte mit Seh-, Hör-, motorischen oder kognitiven Einschränkungen; Menschen mit vorübergehenden Einschränkungen (gebrochener Arm, Augen-OP); situativ Eingeschränkte (Sonnenlicht am Parkplatz, eine Hand frei); Menschen mit Deutsch als Zweitsprache wie Oksana Melnyk; Ältere, z. B. Eltern. Außerdem ist Nachrüsten teurer als barrierefreie Gestaltung von Anfang an, und gute Kontraste, Beschriftungen und Tastaturbedienung verbessern die Usability für alle.

Zuordnung 6 × 0,5 Punkte, Personengruppen 2 × 1 Punkt:

Bei Nr. 4 ist auch „wahrnehmbar“ vertretbar, bei Nr. 6 „bedienbar“, wenn begründet wird, dass die Liste ohne Kartenbedienung auskommt.

Je Beobachtung 2 Punkte (Barriere 1 Punkt, Abhilfe 1 Punkt), z. B.:

1. Barriere: Die Funktion ist nur über eine Geste erreichbar, die unsichtbar ist und feine, gleichmäßige Bewegung verlangt. Abhilfe: sichtbare Schaltfläche „Fahrt absagen“ auf der Karte bzw. in der Detailansicht; die Wischgeste darf zusätzlich bleiben. Vor dem Absagen eine Rückfrage, danach „Rückgängig“.

2. Barriere: Zu kleine Zielflächen ohne Abstand führen zu Fehlbedienungen. Abhilfe: Zielflächen von mindestens 24 × 24 CSS-Pixeln, besser rund 44 × 44, mit Abstand zueinander; alternativ eine Auswahlliste der möglichen Platzzahlen.

3. Barriere: Ein festes, kurzes Zeitlimit schließt Menschen aus, die mehr Zeit brauchen, und der Datenverlust zwingt zum Neuanfang. Abhilfe: Zeitlimit deutlich länger oder abschaltbar, Warnung vor Ablauf mit „Sitzung verlängern“, Eingaben als Entwurf zwischenspeichern.

Je Regel 1,5 Punkte (Beurteilung mit Begründung 1 Punkt, bessere Regel bzw. Bestätigung 0,5 Punkte), z. B.:

1. ungeeignet: Text in durchgehenden Großbuchstaben ist schwerer zu lesen, weil die Wortform (Ober- und Unterlängen) fehlt; Screenreader buchstabieren manche Großbuchstabenwörter. Besser: normale Groß- und Kleinschreibung; hervorheben über Größe, Schriftstärke oder Position.

2. ungeeignet: Die App wird aus 30 bis 40 cm gelesen, die Monitore aus einigen Metern im Vorbeigehen. Besser: Schriftgröße nach Leseabstand festlegen und vor Ort aus der größten üblichen Entfernung testen; lieber weniger Einträge, dafür groß.

3. ungeeignet: Schmale, dünne Schnitte verschwimmen aus der Entfernung und bei Gegenlicht; überfüllte Bildschirme überfordern. Besser: normale bis halbfette Schrift, großzügiger Zeilenabstand, wenige Fahrten je Ansicht und automatisch weiterblättern – mit genug Zeit zum Lesen.

4. geeignet: Große Kleinbuchstaben (x-Höhe) und eindeutige Zeichen verbessern die Lesbarkeit, besonders für Menschen mit Sehschwäche oder Legasthenie, und vermeiden Verwechslungen bei Uhrzeiten und Raumnummern.

Je Zeile 1 Punkt (5 Punkte), weiteres Problem 2 Punkte. Grenzwerte (Stufe AA): normaler Text 4,5 : 1, große Schrift (ab 24 px bzw. ab 18,66 px fett) 3 : 1, grafische Elemente und Bedienelemente 3 : 1.

Weiteres Problem (2 Punkte): Der Status wird nur über die Farbe Rot oder Grün vermittelt. Menschen mit Rot-Grün-Sehschwäche (etwa 8 % der Männer) können „frei“ und „voll“ nicht unterscheiden, und aus der Entfernung oder im Gegenlicht ist die Farbe schwer erkennbar. Lösung: Status zusätzlich als Text („2 Plätze frei“, „voll“) bzw. mit unterschiedlichen Symbolen anzeigen.

Barrieren, 4 × 1,5 Punkte (6 Punkte), z. B.:

• Schaltfläche ist ein div mit Bild: Sie ist mit der Tastatur nicht erreichbar, wird vom Screenreader nicht als Schaltfläche angesagt, und das Pfeilbild hat keinen Text; Lukas weiß nicht, dass und wie er die Anfrage abschicken kann.

• Eingabefelder ohne Beschriftung: Nur Platzhalter, keine label; der Screenreader sagt nur „Eingabefeld“ an, der Platzhalter verschwindet zudem beim Tippen.

• Logo ohne Alternativtext: Der Screenreader liest den Dateinamen vor.

• Keine Sprache angegeben (lang fehlt): Die Sprachausgabe kann falsch aussprechen.

• Pflichtfeld-Kennzeichnung nur als rotes Sternchen ohne Bezug: Es ist nicht erkennbar, welches Feld gemeint ist; für den Screenreader ist das Sternchen bedeutungslos.

• Datum als Freitext mit festem Format: fehleranfällig; besser ein Datumsfeld.

• Überschriftenhierarchie: Die Seite beginnt mit h3, es fehlt h1; die Navigation per Überschriften ist gestört.

Verbesserter Code, 4 Punkte (je behobener Barriere 1 Punkt), z. B.:

<html lang="de">
<body>
  <img src="img/ratzfahrt-logo.png" alt="RatzFahrt">
  <main>
    <h1>Mitfahrt anfragen</h1>
    <p>Felder mit * sind Pflichtfelder.</p>
    <form>
      <label for="haltepunkt">Haltepunkt *</label>
      <input type="text" id="haltepunkt" name="haltepunkt" required autocomplete="off">

      <label for="datum">Datum *</label>
      <input type="date" id="datum" name="datum" required>

      <button type="submit">Mitfahrt anfragen</button>
    </form>
  </main>
</body>
</html>

Statt des Freitextfeldes für den Haltepunkt ist auch eine Auswahlliste (select) der Haltepunkte sinnvoll.

Zwei Möglichkeiten, 2 × 2 Punkte, z. B.:

• Automatisierte Prüfung: Ein Prüfwerkzeug (z. B. Lighthouse oder axe in den Browser-Entwicklerwerkzeugen) durchsucht die Seiten nach fehlenden Alternativtexten, Beschriftungen, zu geringen Kontrasten und fehlerhaftem HTML und listet die Fundstellen auf.

• Manueller Test nur mit der Tastatur: Eine Person bedient alle Funktionen ohne Maus (Tab, Umschalt+Tab, Enter, Leertaste) und prüft, ob alles erreichbar, der Fokus sichtbar und die Reihenfolge logisch ist.

• Test mit Screenreader: Das Team bedient die App mit NVDA bzw. TalkBack und VoiceOver und prüft, ob alle Inhalte und Bedienelemente verständlich angesagt werden.

• Usability-Test mit betroffenen Personen: Lukas Hofmann und weitere Nutzende von Hilfstechnologien erledigen typische Aufgaben (Fahrt suchen, Mitfahrt anfragen); Probleme werden beobachtet und dokumentiert.

• Prüfung nach einem standardisierten Verfahren (z. B. BITV-Test bzw. Prüfschritte nach EN 301 549/WCAG), ggf. durch eine externe Prüfstelle.

• Vergrößerungs- und Farbtest: Darstellung bei 200 % Schrift bzw. 400 % Zoom, Kontrastprüfer, Simulation von Farbsehschwächen.

Erläuterung, 2 Punkte, z. B.: Automatische Werkzeuge erkennen nur technisch prüfbare Fehler und damit nur einen Teil der Barrieren. Ob ein Alternativtext sinnvoll ist, ob die Tab-Reihenfolge logisch ist, ob Fehlermeldungen verständlich sind oder ob ein Ablauf mit Screenreader tatsächlich nutzbar ist, kann nur ein Mensch beurteilen. Ein fehlerfreies Prüfprotokoll bedeutet also nicht, dass die App barrierefrei ist.

3 × 1 Punkt, z. B.:

• Stand der Vereinbarkeit mit den Anforderungen (vollständig, teilweise oder nicht barrierefrei)

• Liste der Inhalte, die (noch) nicht barrierefrei sind, mit Begründung und ggf. barrierefreien Alternativen

• Feedback-Mechanismus bzw. Kontaktmöglichkeit, um Barrieren zu melden oder barrierefreie Informationen anzufordern

• Hinweis auf die Durchsetzungs- bzw. Schlichtungsstelle

• Datum der Erstellung bzw. letzten Überprüfung (mindestens jährlich zu aktualisieren)

Kriterium und Kennzahl je 1 Punkt (3 Punkte), Berechnung 2 Punkte, Empfehlung 2 Punkte:

Empfehlung: Variante B ist in allen drei Kriterien besser. Mehr Personen kommen ohne Hilfe zum Ziel, sie brauchen im Mittel rund 45 Sekunden weniger und bewerten die Bedienung deutlich besser. Die Liste passt zur eigentlichen Aufgabe („möglichst bald einen Termin“): Wer einen bestimmten Tag braucht, kann über „weitere Termine anzeigen“ trotzdem weiterblättern. Einschränkung: Zehn Personen je Variante sind wenig; die Unterschiede sind aber deutlich und in allen Kriterien gleichgerichtet.

• Rechnung (1 Punkt): Die Rechnung stimmt: A (2155 + 365) s / 10 = 252 s, B (2365 + 180) s / 10 = 254,5 s.

• Bewertung (3 Punkte): Die Aussage stützt Variante A nicht. In den Mittelwert gehen die Personen ein, die aufgegeben haben, und ihre Zeiten sind kurz, gerade weil sie gescheitert sind. Je mehr Personen früh abbrechen, desto „schneller“ wirkt eine Variante. Effizienz darf nur für erfolgreich erledigte Aufgaben gemessen werden; Abbrüche gehören zur Effektivität. Bei sauberer Trennung ist B schneller und erfolgreicher.

Anrufe 2 Punkte, Kosten und Amortisation 3 Punkte, weiterer Nutzen 1 Punkt:

• App-Nutzende pro Woche: 75 · 0,8 = 60. Erfolgreich mit A: 60 · 0,7 = 42 (es bleiben 33 Anrufe), mit B: 60 · 0,9 = 54 (es bleiben 21 Anrufe). B spart 12 Anrufe pro Woche zusätzlich.

• Zeit: 12 · 6 min = 72 min pro Woche; 72 min · 46 = 3.312 min = 55,2 h im Jahr; 55,2 h · 50 €/h = 2.760 € im Jahr.

• Amortisation: 2.300 € / 2.760 € pro Jahr ≈ 0,83 Jahre = 10 Monate.

• Nicht eingerechnet, z. B.: zufriedenere Kundschaft und bessere Bewertungen, weniger Unterbrechungen und Fehler in der Werkstatt (Konzentration), Menschen mit wenig Technikerfahrung buchen eher selbst, weniger Fehlbuchungen und Rückfragen.

Je ungeeignetem Element 2 Punkte (Begründung 1 Punkt, Vorschlag 1 Punkt), passendes Element 1 Punkt:

Passend: Abgabe als Optionsschaltflächen – es gibt genau zwei sich ausschließende Möglichkeiten, beide sind ohne weiteren Tipp sichtbar, und eine sinnvolle Vorbelegung ist gesetzt.

Zuordnung 10 × 0,5 Punkte (5 Punkte), zwei Begründungen je 1 Punkt. Abweichende Zuordnungen sind richtig, wenn sie begründet sind.

• Startansicht: 1, 2, 5, 6 – das braucht das Team in jedem Moment, um zu entscheiden, ob und wohin es gehen muss.

• Detail- oder Verlaufsseite: 3, 4, 7 – wichtig für die Fehlersuche an einem bestimmten Gerät, aber nicht für den Überblick. Ein Akkustand gehört auf die Startansicht erst, wenn er zur Störung wird (z. B. unter 20 %).

• Nicht in die App: 8, 9, 10 – keine Aufgabe des Technikteams (Check-in-Zahlen interessieren das Orga-Team) bzw. reine Dekoration, die auf dem kleinen Bildschirm die Störungen nach unten schiebt.

Beispielbegründungen:

• Aufgabenangemessenheit: Die Startansicht zeigt nur, was zum Erkennen und Übernehmen von Störungen nötig ist; IP-Adressen, Wetter oder Titelbild würden davon ablenken und bei Einhandbedienung zusätzliches Scrollen erzwingen.

• Selbstbeschreibungsfähigkeit: Der Zeitpunkt der letzten Aktualisierung zeigt, ob die angezeigten Zustände aktuell sind – sonst hält das Team ein ausgefallenes Gerät für „ok“, weil die Anzeige nur veraltet ist.

• Erwartungskonformität: Die Zusammenfassung „x von y ok“ je Gruppe entspricht dem, was das Team aus der Planung kennt (zehn Monitore, zwölf Türschilder), Abweichungen fallen sofort auf.

Bewertungsvorschlag (8 Punkte):

• offene Störungen ganz oben, je Störung Gerät, Ort und Beginn (2 Punkte)

• Zuständigkeit sichtbar und Schaltfläche zum Übernehmen, groß genug für einen Daumen (2 Punkte)

• Zusammenfassung der übrigen Gerätegruppen (1 Punkt)

• Zeitpunkt der letzten Aktualisierung (1 Punkt)

• Navigation zu Detail- bzw. Verlaufsseiten im Daumenbereich unten (1 Punkt)

• Zustände nicht nur über Farbe, sondern mit Text bzw. Symbol („Noch niemand zuständig“, Haken-Symbol) (1 Punkt)

Andere Anordnungen sind richtig, wenn die Störungen Vorrang haben und die Bedienung mit einer Hand möglich bleibt.

Je Vorschlag 1,5 Punkte, Empfehlung 1,5 Punkte, z. B.:

• Vorschlag 1: Zu viele, nicht priorisierte Meldungen an alle: Nach kurzer Zeit werden sie weggewischt oder stumm geschaltet, auch die wichtigen. Niemand fühlt sich zuständig, oder mehrere laufen gleichzeitig los. Ein Ton allein geht in der lauten Aula unter.

• Vorschlag 2: Das Vollbildfenster unterbricht jede andere Tätigkeit in der App und verdeckt die übrigen Störungen (Steuerbarkeit). Rotes Blinken kann bei Menschen mit Epilepsie Anfälle auslösen (WCAG: höchstens drei Blitze pro Sekunde), und eine Sirene erschreckt Teilnehmende in Sessions.

• Vorschlag 3: Die Meldung erreicht gezielt die zuständige Person, über zwei Sinne (Vibration und Ton – auch bei Lärm wahrnehmbar). Die Eskalation nach fünf Minuten sorgt dafür, dass keine Störung liegen bleibt; unwichtige Meldungen stören nicht.

• Empfehlung: Vorschlag 3, ggf. ergänzt um einen deutlichen, aber nicht blinkenden Hinweis in der App, solange eine Störung unbearbeitet ist.