In che modo l'utilizzo dei diagrammi di stato può renderti un migliore Web Coder

Uno strumento che dovrebbe essere nel tuo arsenale di codifica web è il diagramma di stato. Un diagramma di stato mostra i vari "stati" (reazioni) che la tua applicazione (ad es., Sito web) può contenere, nonché quale azione o input (da parte dell'utente) è necessario per raggiungere uno stato specifico. Un diagramma di stato aiuta a concretizzare nella mente tutte le possibili interazioni utente / applicazione. Questo aumenta le probabilità che tu possa almeno prendere in considerazione la codifica per tutte le possibilità semplicemente perché ora le conosci tutte - il che riduce le possibilità che hai codice buggy o peggio, dimentica di gestire funzionalità specifiche.

Perché usare un diagramma di stato?

Un diagramma di stato è costituito da due componenti: cerchi per rappresentare gli stati (reazioni / output dell'applicazione) e frecce per rappresentare le transizioni (azioni / input dell'utente). I diagrammi di stato sono molto utili per applicazioni di computer complesse e non così complesse di alcun tipo. Tuttavia, quando si tratta di sviluppo di siti Web, i diagrammi di stato non sono sempre utili:

  1. Se si dispone di un sito Web statico in cui la navigazione garantisce che ogni singola pagina si collega a tutte le altre pagine, quindi un diagramma di stato è ridondante. (Nel ramo della matematica chiamata Teoria dei grafi, questa situazione è conosciuta come un "grafico completamente connesso". Un grafico è un insieme di spigoli e nodi - cioè, transizioni e stati).
  2. Se si dispone di un sito Web dinamico in esecuzione su un CMS (Content Management System), che include piattaforme per blog, allora gran parte delle transizioni di stato sono già codificate nel sito. Quindi, ancora una volta, un diagramma di stato non è molto utile.

D'altra parte, se stai costruendo un sito web in cui devi gestire transizioni speciali, allora un diagramma di stato può essere di grande beneficio:

  1. Gestione dell'input utente speciale, in cui ciò che selezionano decide lo stato successivo. (Ad es. Moduli o menu con elenchi a discesa o dinamici).
  2. AJAX-y siti dove anche dopo una significativa azione dell'utente, l'URL non cambia. (Il contenuto lo fa, URL no.)

Come si creano diagrammi di stato?

La cosa sorprendente è che i diagrammi di stato non sono così complicati da produrre. Tuttavia, secondo la mia esperienza, non vengono utilizzati spesso dalla maggior parte dei programmatori, nonostante i vantaggi (comprensione più profonda delle interazioni dell'utente, coesione dello sforzo di codifica). Giuro per loro - o fatto quando stavo codificando ogni giorno in vari lavori.

Si consiglia di produrre prima diagrammi di stato su carta, quindi trasferirli su una copia digitale se e solo se necessario. (C'è qualcosa nella tattilità di abbozzare le relazioni input / display su carta che le rende più concrete nella tua mente, rendendo più facile accomodare tutte le possibili interazioni e quindi ridurre i bug nelle tue applicazioni.)

Un diagramma di stato è composto da:

  • Linee freccia etichettate per mostrare input / azioni dell'utente (transizione).
  • Cerchi etichettati per mostrare la visualizzazione del contenuto risultante (stato dell'applicazione).
  • Inizia stato con un cerchio a doppio bordo.
  • Stati di fine (ma non quando l'applicazione è basata sul Web. Vedi sotto per una spiegazione).

Puoi vedere un semplice esempio direttamente qui sotto, che verrà espanso più avanti in questo articolo:

Ecco i passaggi per la creazione di diagrammi di stato (con una tendenza verso le applicazioni basate sul sito Web):

  1. Crea una lista di tutti i possibili input da parte dell'utente dell'applicazione, da ogni singolo stato.
  2. Disegna lo stato di avvio: un cerchio a doppio bordo etichettato con "S". Con un sito Web, lo stato iniziale è la pagina iniziale e il display predefinito.
  3. Disegna cerchi per eventuali stati o sotto-stati unici. Per i siti statici, ogni pagina Web è uno stato separato. Se per la tua app web possono avere diversi stati secondari per lo stesso URL, devi disegnare circoli di stato separati.
  4. Per ogni azione possibile dallo stato di partenza, disegna frecce etichettate (transizioni) al cerchio dello stato successivo possibile.
  5. Ripetere questo da ogni stato fino a quando non si dispone di un diagramma di stato completo per l'applicazione.
  6. Non dimenticare le transizioni circolari. Ad esempio, da uno stato a se stesso (probabilmente a causa del doppio clic sullo stesso collegamento due volte).
  7. Le transizioni ripetitive da un cluster di stati correlati possono essere rappresentate con una forma breve, come verrà discusso di seguito.
  8. I diagrammi di stato per applicazioni non Web hanno quasi sempre uno stato "Fine". Tuttavia, si dice che il Web sia "senza stato" perché in un browser web, ogni singolo stato è uno stato finale. Puoi prendere un'azione e andartene, o prendere un'altra azione e poi lasciare, ecc. Quindi, per le applicazioni Web, non è necessario disegnare lo stato Fine.

Per espandere il numero 7 in alto, tieni presente che con i siti web potrebbero esserci molte ripetizioni di azioni. Ad esempio, se ogni pagina include lo stesso menu di navigazione, non è necessario mostrare tali transizioni più e più volte e creare confusione nel diagramma di stato. Rappresenta solo azioni raggruppate con qualche notazione / simbolo di forma breve.

(È molto più facile capire un diagramma di stato se sei la persona che lo disegna, un passo alla volta. Se sei una persona che guarda un diagramma di stato completato, potrebbe essere intimidatorio. Per questo motivo, i diagrammi di stato spesso vivono solo di carta - assumendo che tu li usi.

Come vengono applicati i diagrammi di stato alle applicazioni basate sul sito Web?

Per un sito web statico che utilizza no Le caratteristiche AJAX-y (cioè qualsiasi funzione in cui l'URL non cambia), un diagramma di stato è abbastanza facile da produrre ma generalmente non necessario. Ad esempio, un sito Web statico in cui ogni pagina è connessa ad ogni altra pagina risulta in un diagramma di stato che viene talvolta definito come un grafico "completamente connesso". Tali diagrammi di stato sono in genere inutili perché non c'è una gestione speciale da visualizzare. Ogni stato è connesso a ogni altro stato)

Dove i diagrammi di stato sono più utili è per i siti dinamici, specialmente quelli con Funzioni AJAX-y (come menu a discesa, cursori, fisarmoniche, gallerie, ecc.). In quest'ultimo caso, l'URL nel browser potrebbe non cambiare ma il contenuto della pagina lo fa in modo parziale. È più difficile visualizzare tutti i possibili stati e transizioni (azioni) perché una "pagina" può avere sotto-stati multipli.

Un diagramma di stato (o un insieme di diagrammi sempre più dettagliati) è molto utile in questo caso, specialmente se c'è un gruppo di programmatori (e talvolta di designer) con cui lavorare.

Un esempio di utilizzo del diagramma di stato

In un prossimo tutorial ti mostrerò come codificare il jQuery per due effetti che sto usando nel mio modello AboutMe. La pagina live presenta alcuni errori CSS che devono essere risolti prima. Mi piacerebbe anche aggiungere alcune funzionalità basate su jQuery se c'è abbastanza tempo. Queste funzionalità aggiuntive saranno oggetto del nostro esempio.

In futuro, questo modello si trasformerà in un tema WordPress gratuito destinato ai freelance che vogliono mostrare la propria esperienza di lavoro (concerti). Per ora, voglio mostrare come i diagrammi di stato possono aiutarti a capire la causa / le reazioni necessarie (ovvero input / transizioni) per la galleria "Current Gigs" vista sopra. Comprendere le transizioni necessarie ti aiuta a codificare in modo più sicuro, ed è tutto il linguaggio di codifica indipendente. Quindi puoi decidere sulla libreria / lingua del codice dopo aver creato il diagramma di stato.

Funzionalità dell'applicazione desiderate

Se guardi la galleria "Current Gigs" nel centro a sinistra dell'immagine sopra, o nella pagina live, vedrai che questo è essenzialmente lo stesso concetto di una galleria di immagini. Fare clic su un collegamento e verranno visualizzati i dettagli di tale "concerto". Tuttavia, quando ho creato la pagina live, non c'erano tutorial jQuery su come inserire il testo nel mix, per ogni "frame" della vetrina. Dovevo venire con il mio codice.

Per farlo, ho dovuto prima capire tutte le possibili interazioni con gli utenti. Un diagramma di stato è l'ideale per questo. Alziamo la posta, però. Quello che volevo veramente è una vetrina che mostra sia i concerti attuali che quelli passati. È un po 'come una visuale C.V. (Curriculum Vitae, alias "curriculum"), che mostra una galleria di esperienze lavorative. La cornice di ogni concerto contiene una schermata della home page del sito associato, insieme ad un testo che fornisce i dettagli del lavoro che ho fatto / ci sto facendo.

Per ora, la pagina ha solo "Current Gigs", ma dovrebbe avere anche "Past Gigs". Ecco un elenco dei requisiti funzionali per ciò che l'area vetrina dovrebbe avere:

  1. Interfaccia jQuery a schede, ma "invisibile". Invece di utilizzare le schede normali, utilizza i mini-banner simili al grafico "Ggiere correnti".
  2. Quando si fa clic su una "scheda" (Current Gigs, Past Gigs), viene mostrata la lista di concerti appropriata, insieme al frame (dettagli) del primo elemento.
  3. La vetrina di default è "Current Gigs".
  4. Quando qualcuno fa clic su "Past Gigs", l'elenco dei concerti passati deve essere visualizzato insieme al frame dei dettagli del primo elemento in tale elenco.
  5. Liste di concerti Ogni "scheda" fornirà un elenco di concerti posizionati a sinistra utilizzando una griglia CSS Blueprint.
  6. Le voci dell'elenco dei concerti saranno collegamenti testuali.
  7. Ogni vetrina avrà collegamenti completamente diversi (lavoro passato e presente). Quindi una "esperienza lavorativa" può apparire solo in una vetrina alla volta.
  8. Quando viene cliccato un elemento in una lista di concerti, apparirà la "cornice" dei dettagli del concerto. Ogni fotogramma mostrerà una schermata (precedentemente salvata) e la relativa descrizione del lavoro. Il framework griglia Blueprint verrà utilizzato per posizionare gli elementi della vetrina. (Questo non è necessario, ma è quello che sto puntando.)

Quindi, per reiterare, l'obiettivo è quello di avere un'interfaccia a schede in cui le schede sono etichettate "Current Gigs" e "Past Gigs". Ciò consente più schede in seguito, limitato solo dalla larghezza di ciascuna etichetta e dalla larghezza dello spazio vetrina (590 pixel). Ma voglio che le schede siano "invisibili", come accennato. Invece delle tipiche schede in un'interfaccia a schede, voglio usare mini-banner. Se guardi la pagina del test dal vivo, c'è un mini-banner con l'etichetta "Current Gigs" e un altro con l'etichetta "Past Gigs". Quelle saranno le schede. Ecco una schermata iniziale di come potrebbe apparire l'area della vetrina finale, con le impostazioni predefinite.

Creazione del diagramma di stato

Per creare il diagramma di stato, dobbiamo prima enumerare ogni possibile stato, input e azione:

  1. Stato di partenza: Al caricamento della pagina iniziale:
    1. Nasconde (senza display) tutti i fotogrammi da concerto utilizzando i CSS.
    2. Presentare "Current Gigs" come predefinito.
    3. All'interno della vetrina predefinita, presentare il frame per il primo elemento nell'elenco dei concerti come predefinito. Quindi, ogni volta che qualcuno fa clic sulla scheda "Current Gigs", la vetrina si resetterà da sola.
  2. Possibili azioni generiche dallo stato di avvio:
    1. Clicca su "scheda". Reazione / transizione: esegue il rendering della vetrina corrispondente alla scheda cliccata.
    2. Fare clic su un elemento dell'elenco di gig. Reazione / transizione: renderizza il corrispondente frame dell'oggetto da concerto.
  3. Possibili azioni generiche da altri stati: esattamente lo stesso. Siamo fortunati in questo caso, perché questo rende il diagramma di stato molto più semplice.

Nota: a questo punto, siamo interessati solo a ciò che sta accadendo nella C.V. vetrina. Nel diagramma di stato, non ci interessano le azioni che riguardano altre parti della pagina web. Stiamo solo mostrando azioni / reazioni che influenzano il C.V. vetrina.

Ecco un diagramma di stato di esempio per la funzionalità di cui sopra.

Alcune note su questo diagramma:

  1. Ai fini di questa discussione, non è poi così importante ciò che è effettivamente ogni etichetta. Qui, ognuno rappresenta un sito Web che sto scrivendo per ora o con cui è stato scritto.
  2. Non è complicato come sembra. Concentrati solo su una transizione alla volta e sarà chiaro cosa sta succedendo. [Qui, le etichette di azione sono le stesse delle etichette di stato. Non è sempre così.] Di solito è molto più chiaro quando disegni il diagramma da solo, aggiungendo nuove circonferenze e frecce di transizione una alla volta.
  3. Le transizioni, dette anche azioni dell'utente, sono rappresentate da frecce etichettate. (Normalmente le etichette sarebbero a testo intero, non i moduli brevi usati qui.)
  4. Gli stati, ovvero le reazioni, sono rappresentati da cerchi. Lo stato di partenza è sempre contrassegnato da un doppio cerchio e una "S".
  5. Forme brevi sono utilizzate per entrambi i tipi di etichette, per mantenere il diagramma meno ingombrante.
  6. Gli stati e i sotto-stati sono codificati per colore in base al fatto che siano di natura primaria o secondaria. Ad esempio, il blu rappresenta gli stati primari (e le transizioni). È possibile passare dallo stato di avvio a qualsiasi stato blu con un solo clic sul collegamento appropriato. Non è possibile passare a uno stato viola (secondario) da Inizio senza prima passare attraverso uno stato primario.
  7. Poiché vi è molta transizione ripetitiva (ad esempio, da qualsiasi oggetto di concerto a un altro), i gruppi di transizioni vengono visualizzati con una delle frecce profilate spesse (riempimento blu o viola). Ad esempio, mentre visualizzi i dettagli del concerto FF (FreelanceFolder), puoi fare clic su uno qualsiasi degli elementi del concerto elencati per la vetrina di CG (Current Gigs), incluso lo stesso FF. Oppure puoi cliccare sulla "scheda" CG e resettare la vetrina. Non è possibile passare da una cornice di un concerto "corrente" a una cornice di un concerto "passato", né viceversa.
  8. La freccia blu corta e sottolineata include le transizioni allo stato predefinito di CG. La freccia viola corta e sottolineata non include le transizioni allo stato predefinito di PG. (Questo perché quelle transizioni sono già mostrate esplicitamente. Non erano per CG perché il diagramma sarebbe troppo ingombrante).

Espandendo il punto 5 in alto, la regola generale è che se ci sono più transizioni ripetitive da un gruppo di stati correlati, è possibile annotare le transizioni con una sorta di forma abbreviata. Vuoi semplicemente avere un'idea delle transizioni importanti in modo che siano le prime nella tua mente. Un altro approccio consiste nel prendere un diagramma complesso e dividerlo in parti: panoramica generale, quindi versioni "esplose" di cluster di transizione.

Ad esempio, il diagramma sopra potrebbe avere un diagramma di stato principale contenente i nodi S, CG e PG. Quindi ci sarebbero due diagrammi dettagliati. Uno avrebbe S, CG e i corrispondenti sotto-stati che rappresentano vari concerti. L'altro diagramma dettagliato avrebbe S, PG e i corrispondenti sotto-stati gig.

Pensieri finali

Nel complesso, dovresti ora avere un'immagine più chiara di come funzioni la sezione vetrina. Non ho intenzione di capire come passare da un diagramma di stato a un codice reale. Questo dovrebbe diventare evidente una volta comprese tutte le interazioni dell'utente. Diagrammi di stato - e la tua comprensione di essi dovrebbe aiutarti a scrivere un codice più coeso, riducendo le possibilità di un'applicazione buggy. La tua tecnica di codifica non cambia.