Axure Widget Library – Checkliste für neue Widgets

Im nachfolgenden wird der Begriff Widget und Komponente synonym verwendet.

Die folgende Checkliste dient zur Qualitätssicherung von zentralen Widgets in einer Axure Widget Library. Insbesondere wenn diese Library von mehreren Personen gepflegt wird, entstehen oft unterschiedliche Ausbaustände in der Endversion. Meist erfüllen alle Widgets ihren Zweck und Verhalten sich wie gewünscht, jedoch gibt es einige Kniffe, die wenn beachtet den Kollegen einige Zeit und Frust bei der Verwendung der Widgets ersparen.

Mit diesem Hintergrund ist folgende Checkliste entstanden.

Folgende Punkte sollten erfüllt sein, bevor eine Komponente in einer Axure Widget Library freigegeben ist.

  • Eine Komponente hat einen eindeutigen und sprechenden Namen
  • Eine Komponente ist einer beschreibenden Gruppe zugeordnet (Beispiele: Basiselemente, funktionale Elemente, zusammengesetzte Komponenten)
  • Alle Elemente der Komponente sind zusammen gruppiert, die Gruppe ist gleichnamig zum Widget. Diese Maßnahme erleichtert es im späteren Projekt das Widget/die Komponente wiederzufinden bzw. zu suchen. Gleichzeitig bleiben die zusammengehörigen Elemente gruppiert und es entsteht kein „Salat“ aus Bausteinen, welche auf der Projekt-Prototypenseite zusammengewürfelt sind. Besteht das Widget aus einem dynamischen Panel, so ist das dynamische Panel trotzdem zu gruppieren.
Beispiel für eine Gruppierung
Axure Elemente sind gruppiert und die Gruppierung ist gleichnamig zur Komponente.
  • Die Komponente ist in sich funktional –  bei einer Auswahlliste (Dropdown) klappt zum Beispiel die Liste aus wenn auf das Icon für „Erweitern“ gedrückt wird und verschwindet wieder wenn das Icon für „Zusammenklappen“ gedrückt wird.
  • Alle Elemente des Widgets sind sauber benannt.
  • Das Widget verwendet nach Möglichkeit nur die eigenen Styles (bspw.: „IF_Icon Farbe Füllung„) oder eigens für das Widget definierte Styles (bspw.: „Dropdown Iconfarbe„). Dies ermöglicht es später in Projekten Farbänderungen einfacher umzusetzen und genau abzugrenzen.
  • Das Widget hat alle adaptiven Ansichten definiert, sofern dieses Feature verwendet wird. Widgets, die in einer bestimmten Ansicht keinen Sinn machen, werden aus der entsprechenden Ansicht gelöscht. Das Fehlen der mobilen Variante wird in der Seitennotiz „Mobiles Verhalten“ begründet und vermerkt, ebenso wie andere Verhaltensänderungen.
Die mobile Ansicht ist durch eine Notiz erklärt.
  • Das Widget verwendet keine globalen Variablen.
  • Es ist ein Icon hinterlegt für beide Icon-Felder (28 x 28 px & 56 x 56 px)
  • Die Check In-Notiz enthält eine explizite Auflistung aller erstellten Komponenten (eigene Sektion innerhalb der Nachricht).
Erstellt:
#Drowdown 1/1
#Dropdown 1/3
im Rahmen von TICKET-123.
----
Verändert:
..
....
----
Gelöscht:
....

Eine ähnliche Form dieser Checkliste verwenden wir um im Rahmen des Prototypings von Oberflächen, um zu gewährleisten, dass alle Widgets grundlegende Standards einhalten, was das Arbeiten deutlich vereinfacht. Da die Komponenten einer zentralen Komponentenbibliothek jedoch in vielen Projekten zum Einsatz kommen, ist es wichtig diese Standards zu forcieren, um das Arbeiten mit diesen Widgets erheblich zu vereinfachen und nacharbeiten zu verringern.
Jeder Planer kann sich somit sicher sein, dass wenn er beispielsweise die zum Widget hinterlegten Styles bearbeitet, er auch wirklich nur für diese Widgets Farb-/Stilanpassungen vornimmt. Würde das Widget beispielsweise Axure Default-Styles (Box1, Linie, …) verwenden, so könnte eine Farbänderung in allen möglichen Komponenten seines Projektes „durchschlagen“, was unnötige Nacharbeiten nach sich ziehen könnte.

Durch die Bereitstellung und Abarbeitung dieser Checkliste wird geholfen, diesen Mindeststandard zu dokumentieren und nachzuhalten.