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.
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:
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:
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:
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):
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.
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.
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.
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:
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.
Per creare il diagramma di stato, dobbiamo prima enumerare ogni possibile stato, input e azione:
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:
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.
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.