Wie Sie die Verwendung von Zustandsdiagrammen zu einem besseren Webcodierer machen können

() translation by (you can also view the original English article)

Ein Werkzeug, das in Ihrem Webcodierungsarsenal enthalten sein sollte, ist das Zustandsdiagramm. Ein Zustandsdiagramm zeigt die verschiedenen "Zustände" (Reaktionen), in denen sich Ihre Anwendung (z.B. Website) befinden kann, sowie welche Aktion oder Eingabe (vom Benutzer) erforderlich ist, um zu einem bestimmten Zustand zu gelangen. Ein Zustandsdiagramm hilft Ihnen dabei, alle möglichen Benutzer- / Anwendungsinteraktionen in Ihrem Kopf zu konkretisieren. Das erhöht die Wahrscheinlichkeit, dass Sie zumindest in Betracht ziehen, alle Möglichkeiten zu codieren, nur weil Sie sie jetzt alle kennen. Das verringert die Wahrscheinlichkeit, dass Sie fehlerhaften Code haben oder schlimmer noch, bestimmte Funktionen vergessen haben.

Warum ein Zustandsdiagramm verwenden?

Ein Zustandsdiagramm besteht aus zwei Komponenten: Kreise zur Darstellung von Zuständen (Anwendungsreaktionen / Ausgabe) und Pfeile zur Darstellung von Übergängen (Benutzeraktionen / Eingabe). Zustandsdiagramme sind sehr praktisch für komplexe und weniger komplexe Computeranwendungen jeglicher Art. Bei der Entwicklung von Websites sind Zustandsdiagramme jedoch nicht immer von Nutzen:

Wenn Sie eine statische Website haben, auf der die Navigation garantiert, dass jede einzelne Seite mit jeder anderen Seite verknüpft ist, ist ein Statusdiagramm redundant. (In dem Zweig der Mathematik, der als Graphentheorie bezeichnet wird, ist diese Situation als "vollständig verbundener Graph" bekannt. Ein Graph ist eine Menge von Kanten und Knoten - d. H. Übergängen und Zuständen.)
Wenn Sie eine dynamische Website auf einem CMS (Content Management System) ausführen, das Blog-Plattformen enthält, sind so viele Statusübergänge bereits in Ihrer Website codiert. Ein Zustandsdiagramm ist also wiederum nicht sehr nützlich.

Wenn Sie jedoch eine Website erstellen, auf der Sie spezielle Übergänge verarbeiten müssen, kann ein Zustandsdiagramm von großem Vorteil sein:

Behandlung spezieller Benutzereingaben, bei denen das, was sie auswählen, über den nächsten Status entscheidet. (Zum Beispiel Formulare oder Menüs mit Dropdown- oder dynamischen Listen.)
AJAX-y-Sites, bei denen sich die URL auch nach einer signifikanten Benutzeraktion nicht ändert. (Inhalt tut, URL nicht.)

Wie erstellen Sie Zustandsdiagramme?

Das Überraschende ist, dass Zustandsdiagramme nicht allzu kompliziert zu erstellen sind. Nach meiner Erfahrung werden sie von den meisten Programmierern trotz der Vorteile (tieferes Verständnis der Benutzerinteraktionen; Zusammenhalt des Codierungsaufwands) nicht allzu oft verwendet. Ich schwöre bei ihnen - oder tat es, als ich jeden Tag in verschiedenen Jobs programmierte.

Es wird empfohlen, zuerst Zustandsdiagramme auf Papier zu erstellen und diese dann genau dann auf eine digitale Kopie zu übertragen, wenn das erforderlich ist. (Die Taktilität des Skizzierens von Eingabe- / Anzeigebeziehungen auf Papier hat etwas Konkretes in Ihrem Kopf, das es einfacher macht, alle möglichen Interaktionen zu berücksichtigen und so Fehler in Ihren Anwendungen zu reduzieren.)

Ein Zustandsdiagramm besteht aus:

Beschriftete Pfeillinien zur Anzeige von Benutzereingaben / -aktionen (Übergang).
Beschriftete Kreise, um die resultierende Anzeige des Inhalts anzuzeigen (Anwendungsstatus).
Beginnen Sie den Status mit einem doppelten Kreis.
Endzustände (jedoch nicht, wenn die Anwendung webbasiert ist. Eine Erklärung finden Sie weiter unten.)

Sie können ein einfaches Beispiel direkt unten sehen, das später in diesem Artikel erweitert wird:

Hier sind die Schritte zum Erstellen von Zustandsdiagrammen (mit Blick auf website-basierte Anwendungen):

Erstellen Sie eine Liste aller möglichen Eingaben des Anwendungsbenutzers aus jedem einzelnen Status.
Zeichnen Sie den Startstatus - einen doppelten Kreis mit der Bezeichnung "S". Bei einer Website ist der Startstatus die Startseite und ihre Standardanzeige.
Zeichnen Sie Kreise für einen möglichen eindeutigen Zustand oder Unterzustand. Bei statischen Websites ist jede Webseite ein separater Status. Wenn Ihre Web-App unterschiedliche Unterzustände für dieselbe URL haben kann, müssen Sie separate Zustandskreise zeichnen.
Zeichnen Sie für jede mögliche Aktion vom Startzustand aus beschriftete Pfeile (Übergänge) zum Kreis des nächstmöglichen Zustands.
Wiederholen Sie diesen Vorgang für jeden Status, bis Sie ein vollständiges Statusdiagramm für die Anwendung haben.
Vergessen Sie nicht die kreisförmigen Übergänge. Zum Beispiel von einem Zustand zurück zu sich selbst (möglicherweise aufgrund eines zweimaligen erneuten Klickens auf denselben Link).
Wiederholte Übergänge von einem Cluster verwandter Zustände können mit einer Kurzform dargestellt werden, wie nachstehend erläutert wird.
Zustandsdiagramme für Nicht-Webanwendungen haben fast immer den Status "End". Das Web wird jedoch als "zustandslos" bezeichnet, da in einem Webbrowser jeder einzelne Status ein Endstatus ist. Sie können eine Aktion ausführen und verlassen oder eine andere Aktion ausführen und dann verlassen usw. Für Webanwendungen ist es also nicht erforderlich, den Endstatus zu zeichnen.

Um #7 oben zu erweitern, denken Sie daran, dass es bei Websites zu vielen Wiederholungen von Aktionen kommen kann. Wenn beispielsweise jede Seite dasselbe Navigationsmenü enthält, müssen diese Übergänge nicht immer wieder angezeigt werden und das Zustandsdiagramm überladen. Stellen Sie einfach gruppierte Aktionen mit einer Kurznotation / einem Symbol dar.

(Es ist viel einfacher, ein Zustandsdiagramm zu verstehen, wenn Sie die Person sind, die es Schritt für Schritt zeichnet. Wenn Sie ein fertiges Zustandsdiagramm betrachten, kann das einschüchternd sein. Aus diesem Grund leben Zustandsdiagramme häufig nur in Papierform - vorausgesetzt, Sie verwenden sie.

Wie gelten Zustandsdiagramme für Website-basierte Anwendungen?

Für eine statische Website, die keine AJAX-y-Funktionen verwendet (d. H. Alle Funktionen, bei denen sich die URL nicht ändert), ist ein Zustandsdiagramm relativ einfach zu erstellen, aber im Allgemeinen nicht erforderlich. Beispielsweise führt eine statische Website, auf der jede Seite mit jeder anderen Seite verbunden ist, zu einem Zustandsdiagramm, das manchmal als "vollständig verbundenes" Diagramm bezeichnet wird. Solche Zustandsdiagramme sind normalerweise sinnlos, da keine spezielle Behandlung zu visualisieren ist. Jeder Staat ist mit jedem anderen Staat verbunden.

Zustandsdiagramme eignen sich am besten für dynamische Websites - insbesondere für Websites mit AJAX-y-Funktionen (z. B. Drop-Menüs, Schieberegler, Akkordeons, Galerien usw.). Im letzteren Fall ändert sich die URL im Browser möglicherweise nicht, der Seiteninhalt jedoch teilweise. Es ist schwieriger, alle möglichen Zustände und Übergänge (Aktionen) zu visualisieren, da eine "Seite" mehrere Unterzustände haben kann.

Ein Zustandsdiagramm (oder eine Reihe von immer detaillierteren Diagrammen) ist in diesem Fall sehr praktisch - insbesondere, wenn ein Team von Codierern (und manchmal auch Designern) zur Verfügung steht.

Ein Beispiel für die Verwendung von Zustandsdiagrammen

In einem kommenden Tutorial werde ich Ihnen zeigen, wie Sie die jQuery für zwei Effekte codieren, die ich in meiner AboutMe-Vorlage verwende. Die Live-Seite enthält einige CSS-Probleme, die zuerst behoben werden müssen. Ich möchte auch einige weitere jQuery-basierte Funktionen hinzufügen, wenn genügend Zeit vorhanden ist. Diese zusätzlichen Funktionen werden Gegenstand unseres Beispiels sein.

In Zukunft wird diese Vorlage zu einem kostenlosen WordPress-Theme für Freiberufler, die ihre Arbeitserfahrung (Gigs) präsentieren möchten. Im Moment möchte ich zeigen, wie Zustandsdiagramme Ihnen helfen können, die notwendigen Ursachen / Reaktionen (auch bekannt als Input / Übergänge) für die oben gezeigte Galerie "Current Gigs" zu verstehen. Wenn Sie die erforderlichen Übergänge kennen, können Sie sicherer codieren, und alles ist unabhängig von der Codierung. So können Sie nach dem Erstellen des Zustandsdiagramms die Codebibliothek / -sprache festlegen.

Gewünschte Anwendungsfunktionen

Wenn Sie sich die Galerie "Current Gigs" in der Mitte links im Bild oben oder auf der Live-Seite ansehen, werden Sie feststellen, dass das im Wesentlichen dasselbe Konzept wie eine Bildergalerie ist. Klicken Sie auf einen Link und Details zu diesem "Gig" werden angezeigt. Als ich die Live-Seite erstellte, gab es jedoch keine jQuery-Tutorials zum Einfügen von Text in die Mischung für jeden "Frame" des Showcases. Ich musste mir meinen eigenen Code einfallen lassen.

Dazu musste ich zunächst alle möglichen Benutzerinteraktionen verstehen. Ein Zustandsdiagramm ist dafür ideal. Lassen Sie uns den Einsatz erhöhen. Was ich wirklich wollte, ist ein Showcase-Bereich, der sowohl aktuelle als auch vergangene Auftritte zeigt. Es ist wie eine visuelle C.V. (Lebenslauf, auch bekannt als "Lebenslauf"), zeigt eine Galerie mit Arbeitserfahrungen. Der Rahmen jedes Auftritts enthält einen Screenshot der Homepage der zugehörigen Site sowie einen Text mit Details zu der Arbeit, die ich dort gemacht habe / mache.

Im Moment hat die Seite nur "Current Gigs", sollte aber auch "Past Gigs" haben. Hier ist eine Liste der funktionalen Anforderungen für das, was der Vitrinenbereich haben sollte:

JQuery-Oberfläche mit Registerkarten, aber unsichtbar. Verwenden Sie statt den normalen Registerkarten Mini-Banner, die der Grafik "Current Gigs" ähneln.
Wenn Sie auf eine Registerkarte klicken (Aktuelle Gigs, Vergangene Gigs), wird die entsprechende Gig-Liste zusammen mit dem Rahmen (Details) des ersten Elements angezeigt.
Das Standard-Schaufenster ist "Current Gigs".
Wenn jemand auf "Vergangene Auftritte" klickt, muss die Liste der vergangenen Auftritte zusammen mit dem Detailrahmen des ersten Elements in dieser Liste angezeigt werden.
Gigs-Listen. Jede "Registerkarte" enthält eine Liste von Auftritten, die mithilfe eines Blueprint-CSS-Rasters links positioniert sind.
Die Elemente der Gig-Liste sind Textlinks.
Jedes Schaufenster hat völlig unterschiedliche Links (frühere und gegenwärtige Arbeiten). Eine "Berufserfahrung" kann also immer nur in einem Schaufenster gleichzeitig erscheinen.
Wenn Sie auf ein Element in einer Gig-Liste klicken, wird der "Frame" des Gig-Details angezeigt. Jeder Frame zeigt einen Screenshot (zuvor gespeichert) und die zugehörige Jobbeschreibung. Das Blueprint CSS grid framework wird verwendet, um die Präsentationselemente zu positionieren. (Es ist nicht notwendig, aber das ist mein Ziel.)

Um es noch einmal zu wiederholen, ist das Ziel eine Oberfläche mit Registerkarten, auf der die Registerkarten mit "Current Gigs" und "Past Gigs" gekennzeichnet sind. Das hilft später weitere Registerkarten, die nur durch die Breite jedes Etiketts und die Breite des Präsentationsbereichs (590 Pixel) begrenzt sind. Aber ich möchte, dass die Registerkarten, wie erwähnt, "unsichtbar" sind. Anstelle der typischen Registerkarten in einer Registerkartenoberfläche möchte ich Mini-Banner verwenden. Wenn Sie sich die Live-Testseite ansehen, gibt es ein Mini-Banner mit der Bezeichnung "Current Gigs" und ein weiteres mit der Bezeichnung "Past Gigs". Das werden die Registerkarten sein. Hier ist eine Nahaufnahme des Bildschirmansichts, wie der endgültige Präsentationsbereich mit den Standardeinstellungen aussehen könnte.

Zustandsdiagramm erstellen

Um das Zustandsdiagramm zu erstellen, müssen wir zuerst jeden möglichen eindeutigen Zustand, jede Eingabe und jede Aktion auflisten:

Startstatus: Beim Laden der Homepage:
1. Blenden Sie alle Gig-Frames mit CSS aus (nicht anzeigen).
2. Präsentieren Sie standardmäßig "Current Gigs".
3. Präsentieren Sie im Standard-Schaufenster den Rahmen für das erste Element in der Gig-Liste als Standard. Wenn also jemand auf die Registerkarte "Aktuelle Auftritte" klickt, wird das Schaufenster selbst zurückgesetzt.
Mögliche generische Aktionen ab dem Startstatus:
1. Klicken Sie auf "Registerkarte". Reaktion / Übergang: Rendern Sie das Schaufenster entsprechend der angeklickten Registerkarte.
2. Klicken Sie auf einen Gig-Listeneintrag. Reaktion/Übergang: Rendern Sie den entsprechenden Gig-Item-Frame.
Mögliche generische Aktionen aus anderen Staaten: genau das gleiche. Wir haben in diesem Fall das Glück, dass das das Zustandsdiagramm so viel einfacher macht.

Hinweis: An dieser Stelle geht es uns nur darum, was in der C.V. Vitrine. Im Statusdiagramm kümmern wir uns nicht um Aktionen, die andere Teile der Webseite betreffen. Wir zeigen nur Aktionen / Reaktionen, die die C.V. Vitrine.

Hier ist ein Beispiel für ein Zustandsdiagramm für die oben genannte Funktionalität.

Einige Anmerkungen zu diesem Diagramm:

Für die Zwecke dieser Diskussion ist es nicht so wichtig, was jedes Label tatsächlich ist. Hier repräsentiert jeder eine Website, für die ich entweder gerade schreibe oder für die ich geschrieben habe.
Es ist nicht so kompliziert wie es aussieht. Konzentrieren Sie sich immer nur auf einen Übergang und es wird klar, was los ist. [Hier sind die Aktionsbezeichnungen dieselben wie die Statusbezeichnungen. Das ist nicht immer der Fall.] Es ist normalerweise viel klarer, wenn Sie das Diagramm selbst zeichnen und nacheinander neue Zustandskreise und Übergangspfeile hinzufügen.
Übergänge, auch als Benutzeraktionen bezeichnet, werden durch beschriftete Pfeile dargestellt. (Normalerweise sind die Beschriftungen Volltext, nicht die hier verwendeten Kurzformen.)
Zustände, auch Reaktionen genannt, werden durch Kreise dargestellt. Der Startzustand ist immer mit einem Doppelkreis und einem "S" markiert.
Für beide Arten von Beschriftungen werden Kurzformen verwendet, um das Diagramm übersichtlicher zu gestalten.
Die Zustände und Unterzustände sind farbcodiert, je nachdem, ob sie primärer oder sekundärer Natur sind. Zum Beispiel steht Blau für Primärzustände (und Übergänge). Sie können mit einem einzigen Klick auf den entsprechenden Link vom Startstatus in einen beliebigen blauen Status wechseln. Sie können von Start an nicht in einen violetten (sekundären) Zustand wechseln, ohne zuvor einen primären Zustand durchlaufen zu haben.
Da es viele sich wiederholende Übergänge gibt (d. H. Von einem Gig-Gegenstand zu einem anderen), werden Gruppen von Übergängen mit einem der dick umrandeten Pfeile (blaue oder violette Füllung) angezeigt. Während Sie beispielsweise die FF-Gig-Details (FreelanceFolder) anzeigen, können Sie auf eines der Gig-Elemente klicken, die für das CG-Showcase (Current Gigs) aufgeführt sind, einschließlich FF selbst. Oder Sie können auf die CG "Registerkarte" klicken und das Schaufenster zurücksetzen. Sie können nicht von einem "aktuellen" Gig-Frame zu einem "vergangenen" Gig-Frame wechseln oder umgekehrt.
Der kurze, umrandete blaue Pfeil enthält Übergänge zurück zum Standardzustand von CG. Der kurze, umrandete lila Pfeil enthält keine Übergänge zurück zum Standardstatus von PG. (Das liegt daran, dass diese Übergänge bereits explizit angezeigt werden. Sie waren nicht für CG, da das Diagramm viel zu überladen wäre.)

Als Ergänzung zu Punkt #5 gilt als Faustregel, dass Sie bei mehreren sich wiederholenden Übergängen aus einem verwandten Statuscluster die Übergänge mit einer Kurzform versehen können. Sie möchten einfach ein Gefühl für die wichtigen Übergänge bekommen, damit sie in Ihrem Kopf an erster Stelle stehen. Ein anderer Ansatz besteht darin, ein komplexes Diagramm zu erstellen und in Teile aufzuteilen: Hauptübersicht, dann "explodierte" Versionen von Übergangsclustern.

Zum Beispiel könnte das obige Diagramm ein Hauptzustandsdiagramm haben, das die Knoten S, CG und PG enthält. Dann gäbe es zwei detaillierte Diagramme. Man hätte S, CG und die entsprechenden Unterzustände, die verschiedene Gigs repräsentieren. Das andere detaillierte Diagramm hätte S, PG und die entsprechenden Gig-Unterzustände.

Abschließende Gedanken

Insgesamt sollten Sie jetzt ein klareres Bild davon haben, wie der Showcase-Bereich funktioniert. Ich werde nicht darauf eingehen, wie man von einem Zustandsdiagramm zu tatsächlichem Code wechselt. Das muss offensichtlich werden, sobald Sie alle Benutzerinteraktionen verstanden haben. Zustandsdiagramme - und Ihr Verständnis davon sollte Ihnen helfen, zusammenhängenderen Code zu schreiben, wodurch die Wahrscheinlichkeit einer fehlerhaften Anwendung verringert wird. Ihre Codierungstechnik ändert sich nicht.