# Seite 16: Mock-up-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: ```text Mock-up / Benutzeroberflächen-Entwurf ``` Hier übst du, aus einer Aufgabenbeschreibung die wichtigsten Elemente einer Benutzeroberfläche abzuleiten. Im Fokus stehen: ```text Pflichtfelder Fehlermeldungen Validierung Buttons Hauptaktion Nebenaktion Benutzerführung Mock-up ≠ UML-Diagramm ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Pflichtfelder erkennen** | wichtige Felder mit `*` markieren | | **Fehlermeldungen platzieren** | Fehler direkt am betroffenen Feld anzeigen | | **Validierung verstehen** | Eingaben fachlich prüfen | | **Hauptaktion erkennen** | wichtigste Aktion, z. B. Speichern oder Anmelden | | **Nebenaktionen erkennen** | Abbrechen, Zurück, Zurück zur Liste | | **Benutzerführung bewerten** | Oberfläche soll verständlich und logisch sein | | **Mock-up einordnen** | Mock-up ist kein UML-Diagramm | --- **Interaktiver Mock-up-Trainer**
Mock-up-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text Mock-up = geplanter Oberflächenentwurf Mock-up ist kein UML-Diagramm Pflichtfelder müssen erkennbar sein Fehlermeldungen gehören nah an das betroffene Feld Buttons müssen eindeutig beschriftet sein Benutzerführung muss logisch und verständlich sein ``` --- **Beispiel: Produktformular** Aufgabenstellung: ```text Ein Produkt soll angelegt werden. Produktname, Kategorie und Preis sind Pflichtfelder. Der Preis muss größer als 0 sein. Der Benutzer soll speichern, abbrechen oder zurück zur Liste gehen können. ``` Mögliche Lösung: ```text Pflichtfelder: Produktname Kategorie Preis Fehlermeldung: Direkt am Preisfeld Hauptaktion: Speichern Sinnvolle Nebenaktionen: Abbrechen Zurück zur Liste Validierung: Preis muss größer als 0 sein Einordnung: Mock-up ist kein UML-Diagramm ``` --- **Warum ist das fachlich richtig?** Ein Mock-up soll zeigen, wie eine Oberfläche aufgebaut ist und wie der Benutzer sie bedient. Bei einem Produktformular muss der Benutzer erkennen: ```text Welche Daten muss ich eingeben? Welche Felder sind Pflicht? Was ist falsch, wenn eine Eingabe ungültig ist? Wie speichere ich? Wie breche ich ab? Wie komme ich zurück? ``` --- **Pflichtfelder** Pflichtfelder sind Felder, die ausgefüllt werden müssen. Typische Darstellung: ```text Produktname * Kategorie * Preis * ``` Das Sternchen `*` zeigt: ```text Dieses Feld ist erforderlich. ``` --- **Fehlermeldungen** Fehlermeldungen sollten möglichst direkt beim betroffenen Feld stehen. Gut: ```text Preis * [ 0,00 € ] Preis muss größer als 0 sein. ``` Schlecht: ```text Irgendwo oben steht nur: Fehler. ``` Merksatz: ```text Der Benutzer muss sofort erkennen, was falsch ist und wo er es korrigieren muss. ``` --- **Validierung** Validierung bedeutet: ```text Das System prüft, ob die Eingabe gültig ist. ``` Beispiele: ```text Preis muss größer als 0 sein E-Mail-Adresse muss gültig sein Passwort darf nicht leer sein Produktname muss ausgefüllt sein Kategorie muss ausgewählt werden ``` --- **Hauptaktion** Die Hauptaktion ist die wichtigste Aktion im Formular. Beispiele: ```text Speichern Anmelden Bestellung abschließen Absenden ``` Im Produktformular ist die Hauptaktion: ```text Speichern ``` --- **Nebenaktionen** Nebenaktionen helfen dem Benutzer, den Vorgang zu verlassen oder zurückzugehen. Beispiele: ```text Abbrechen Zurück zur Liste Zurück zum Warenkorb Schließen ``` Wichtig: ```text Der Benutzer soll nicht in der Oberfläche feststecken. ``` --- **Mock-up ist kein UML-Diagramm** Ein Mock-up zeigt eine Benutzeroberfläche. Es zeigt nicht: ```text Klassen Methoden Kardinalitäten Sequenzen Kontrollflüsse Datenbankbeziehungen ``` Dafür gibt es andere Diagramme. Merksatz: ```text Mock-up = Oberfläche UML = Modellierung ``` --- **Typische Fehler im Mock-up** | Fehler | Warum problematisch? | |---|---| | Pflichtfelder fehlen | Benutzer weiß nicht, was zwingend ist | | Fehlermeldung fehlt | Benutzer versteht den Fehler nicht | | Fehlermeldung steht zu weit weg | Fehler ist schwer zuzuordnen | | Button heißt nur „OK“ | Aktion ist nicht eindeutig | | Kein Abbrechen-Button | Benutzer kann Vorgang schlecht verlassen | | Kein Rückweg | Benutzerführung ist unvollständig | | Zu viele Elemente | Oberfläche wird unübersichtlich | | Technische Begriffe | Benutzer versteht die Oberfläche schlechter | --- **Mini-Testfragen**
1. Was trainiert dieser Mock-up-Trainer? Er trainiert das Erkennen wichtiger UI-Elemente: ```text Pflichtfelder Fehlermeldungen Validierung Buttons Benutzerführung ```
2. Was bedeutet ein Sternchen `*` an einem Feld? Das Sternchen bedeutet: ```text Pflichtfeld ``` Das Feld muss ausgefüllt werden.
3. Wo sollte eine Fehlermeldung stehen? Möglichst direkt am betroffenen Feld. Beispiel: ```text Preis muss größer als 0 sein. ``` direkt beim Preisfeld.
4. Was ist die Hauptaktion im Produktformular? Die Hauptaktion ist: ```text Speichern ```
5. Welche Nebenaktionen sind sinnvoll? Zum Beispiel: ```text Abbrechen Zurück zur Liste ```
6. Was bedeutet Validierung? Validierung bedeutet: ```text Das System prüft, ob eine Eingabe gültig ist. ``` Beispiel: ```text Preis muss größer als 0 sein. ```
7. Ist ein Mock-up ein UML-Diagramm? Nein. Ein Mock-up ist ein Oberflächenentwurf und kein UML-Diagramm.
8. Was zeigt ein Mock-up nicht? Ein Mock-up zeigt nicht: ```text Programmcode Datenbankbeziehungen Klassendiagramme Sequenzdiagramme Kontrollflüsse ```
9. Warum sind eindeutige Buttons wichtig? Weil der Benutzer erkennen muss, welche Aktion passiert. Besser: ```text Speichern Abbrechen Zurück zur Liste ``` statt: ```text OK Weiter Button 1 ```
10. Was ist Benutzerführung? Benutzerführung bedeutet: ```text Die Oberfläche zeigt dem Benutzer klar, was er tun soll. ``` Dazu gehören: ```text verständliche Feldnamen sichtbare Pflichtfelder klare Buttons Fehlermeldungen Rückwege ```
--- **Nächste Seite** Danach geht es weiter mit: ```text UML-Zustandsdiagramm ```