Freitag, 19. Dezember 2014

Von Erwartungen und Konzepten. Struktur für das User Interface.

Ein System für den Entwurf einer Benutzerschnittstelle.

Artikelübersicht
1. Teil Die Erweiterung des Requirements Engineering durch das Usability Engineering.
2. Teil Mit Zielen zum User Interface.
3. Teil Dem Ziel entspringt die Anforderung. Alles ist im Fluss.
4. Teil Von Erwartungen und Konzepten. Struktur für das User Interface.
5. Teil Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.
6. Teil Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.
7. Teil Elemente verteilen ohne Ausraster.
8. Teil Mit den Sinnen den Sinn der Oberfläche erfassen.


Nach der Strategie- und der Umfangsebene bzw. dem Anforderungsmanagement verlassen wir die abstrakte Ebene und wenden uns Konkreterem zu. Wir treten in die Designphase ein. Diese unterteilt sich nach [GARRETT12] in die Strukturebene, die Rasterebene und die Oberflächenebene. Auch hier verbleiben wir in der Bewegungsrichtung vom Abstrakten zum Konkretem.

Freitag, 5. Dezember 2014

Dem Ziel entspringt die Anforderung. Alles ist im Fluss.

Ein System für den Entwurf einer Benutzerschnittstelle.

Artikelübersicht
1. Teil Die Erweiterung des Requirements Engineering durch das Usability Engineering.
2. Teil Mit Zielen zum User Interface.
3. Teil Dem Ziel entspringt die Anforderung. Alles ist im Fluss.
4. Teil Von Erwartungen und Konzepten. Struktur für das User Interface.
5. Teil Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.
6. Teil Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.
7. Teil Elemente verteilen ohne Ausraster.
8. Teil Mit den Sinnen den Sinn der Oberfläche erfassen.


Im letzten Post wurde der Zielbaum durch spezifische Ziele in Bezug auf das User Interface ergänzt. Im Modell von [GARRETT12] haben wir damit die Strategieebene abgearbeitet. Aus diesen ermittelten Bedürfnissen leiten wir nun konkrete Anforderungen an unsere Benutzeroberfläche ab. Welche Inhalte, welche Funktionen und Workflows soll die Schnittstelle bieten? [GARRATT12] erläutert zwei wichtige Gründe, warum wir uns überhaupt mit der Definition von Anforderungen beschäftigen sollten. Der erste Grund ist, "damit Sie wissen, was Sie entwickeln" [S.59, GARRATT12] und der zweite Grund ist, "damit Sie wissen, was Sie nicht entwickeln". Leider gibt es sehr viele, denen das trivial erscheint und die deshalb auf eine Anforderungsdefinition verzichten. Allen denen, die mit mir glauben, dass gerade trivial erscheinende Dinge sehr schwierig sein können, empfehle ich vor der Umsetzung die Beantwortung der Frage: "Was werden wir entwickeln?" [S.61, GARRATT12]