Hur du använder statliga diagram kan göra dig till en bättre webbkodare

Ett verktyg som borde vara i ditt webbkodningsarsenal är tillståndsdiagrammet. Ett tillståndsdiagram visar de olika "tillstånden" (reaktioner) som din ansökan (t ex webbplats) kan innehålla, samt vilken åtgärd eller inmatning (från användaren) som krävs för att komma till en viss stat. Ett tillståndsschema hjälper till att göra konkreta i åtanke alla möjliga användar- / applikationsinteraktioner. Detta ökar chansen att du åtminstone anser att du kodar för alla möjligheter, helt enkelt för att du nu känner till dem alla - vilket minskar chansen att du har buggy-kod eller sämre, glömde att hantera specifik funktionalitet.

Varför använda ett statligt diagram?

Ett tillståndsdiagram består av två komponenter: cirklar för att representera tillstånd (applikationsreaktioner / utgång) och pilar för att representera övergångar (användaråtgärder / inmatning). Statliga diagram är mycket praktiska för komplexa och inte så komplexa datortillämpningar av något slag. Men när det gäller webbutveckling är statliga diagram inte alltid i bruk:

Om du har en statisk webbplats där navigeringen garanterar att varje enskild sida länkar till varje annan sida, så är ett statligt diagram överflödigt. (I matematikens gräns, kallad Graph Theory, är denna situation känd som en "helt ansluten graf". Ett diagram är en uppsättning kanter och noder - dvs övergångar och tillstånd.)
Om du har en dynamisk webbplats som körs på ett CMS (Content Management System) - som innehåller bloggplattformar - så är så mycket av övergångarna redan kodade till din webbplats. Så återigen är ett statligt diagram inte till stor hjälp.

Å andra sidan, om du bygger en webbplats där du måste hantera särskilda övergångar, då kan ett statsdiagram vara till stor nytta:

Hantering av speciell användarinmatning, där det de väljer väljer nästa tillstånd. (Till exempel formulär eller menyer som har rullgardinsmenyer eller dynamiska listor.)
AJAX-y-platser där även efter en väsentlig användaraktivitet ändras inte webbadressen. (Innehållet gör inte URL.)

Hur skapar du statliga diagram?

Det överraskande är att statliga diagram är inte allt som är komplicerat att producera. Men enligt min erfarenhet används de inte allt så ofta av de flesta programmerare, trots fördelarna (djupare förståelse för användarinteraktioner, sammanhållning av kodningsinsats). Jag svär vid dem - eller gjorde när jag kodade varje dag i olika jobb.

Det rekommenderas att du producerar tillståndsdiagram på papper först och sedan överför dem till en digital kopia om och endast om det är nödvändigt. (Det finns något om taktiliteten för skissningsinmatning / visningsrelationer på papper som gör dem mer konkreta i ditt sinne, vilket gör det lättare att passa alla möjliga interaktioner och därigenom minska buggar i dina applikationer.)

Ett tillståndsdiagram består av:

Märkta pillinjer för att visa användarinmatning / åtgärd (övergång).
Märkta cirklar för att visa den resulterande visning av innehåll (applikationstillstånd).
Starta tillståndet med en dubbelgränsad cirkel.
Sluttillstånd (men inte när ansökan är webbaserad. Se nedan för en förklaring.)

Du kan se ett enkelt exempel direkt nedan - vilket kommer att utvidgas senare i den här artikeln:

Här är stegen för att skapa statliga diagram (med en lutning mot webbaserade applikationer):

Gör en lista över alla möjliga ingångar av applikationsanvändaren, från varje enskilt tillstånd.
Rita startstaten - en dubbelgränsad cirkel märkt med "S". Med en webbplats är startläget hemsidan och dess standardvisning.
Rita cirklar för eventuellt unikt tillstånd eller delstat. För statiska webbplatser är varje webbsida ett separat tillstånd. Om du kan ha olika deltillstånd för samma webbadress för din webbapp, måste du rita separata statscirklar.
För varje möjlig åtgärd från startläget rita märkta pilar (övergångar) till nästa möjliga tillstånds cirkel.
Upprepa detta från varje tillstånd tills du har ett fullständigt tillståndsdiagram för applikationen.
Glöm inte cirkulära övergångar. T.ex. från ett tillstånd till sig själv (möjligen på grund av att du klickar på samma länk två gånger).
Repeterande övergångar från ett kluster av besläktade stater kan representeras med någon kort form, vilket kommer att diskuteras nedan.
Statliga diagram för icke-webbapplikationer har nästan alltid ett "slut" -tillstånd. Men webben sägs vara "statslös" eftersom i en webbläsare är varje stat ett sluttillstånd. Du kan göra en åtgärd och lämna, eller vidta en annan åtgärd och sedan lämna, etc. Så för webbapplikationer är det inte nödvändigt att rita slutstaten.

För att expandera på # 7 ovan, kom ihåg att med webbplatser kan det finnas en hel del repetition av åtgärder. Till exempel om varje sida innehåller samma navigeringsmeny, behöver du inte visa dessa övergångar om och om igen och störa tillståndschemat. Anger bara grupperade handlingar med någon kortformad notation / symbol.

(Det är mycket lättare att förstå ett statligt diagram om du är den som ritar det, ett steg i taget. Om du är en person som tittar på ett färdigt tillståndsdiagram kan det vara skrämmande. Därför lever statsdiagram ofta bara papper - förutsatt att du använder dem.

Hur applicerar statliga diagram på webbaserade applikationer?

För en statisk webbplats som använder Nej AJAX-y-funktioner (dvs alla egenskaper där webbadressen inte ändras) är ett tillståndsdiagram ganska lätt att producera men i allmänhet onödigt. Till exempel, en statisk webbplats där varje sida är kopplad till varje andra sida resulterar i ett statligt diagram som ibland kallas för en "helt ansluten" graf. Sådana tillståndsdiagram är vanligtvis meningslösa eftersom det inte finns någon speciell hantering för att visualisera. Varje stat är ansluten till alla andra stater)

Där statliga diagram är mest praktiska är för dynamiska platser - speciellt de med AJAX-y-funktioner (till exempel droppmenyer, reglage, dragspel, gallerier etc.). I det senare fallet kanske webbläsaren i webbläsaren inte ändras, men sidinnehållet gör det så delvis. Det är svårare att visualisera alla möjliga tillstånd och övergångar (handlingar) eftersom en "sida" kan ha multipel sub-stater.

Ett statligt diagram (eller en uppsättning alltmer detaljerad diagram) är mycket praktisk i det här fallet - speciellt om det finns ett team av kodare (och ibland designare) att arbeta med.

Ett exempel på statligt diagram användning

I en kommande handledning ska jag visa dig hur du kodar jQuery för två effekter jag använder i min AboutMe-mall. Live-sidan har några CSS-glitcher som måste strykas ut först. Jag skulle också vilja lägga till några fler jQuery-baserade funktioner om det finns tillräckligt med tid. Dessa extrafunktioner kommer att vara föremål för vårt exempel.

I framtiden kommer denna mall att bli ett gratis WordPress-tema riktat till frilansare som vill visa upp sitt arbete (spelupplevelse). För nu vill jag visa hur statliga diagram kan hjälpa dig att förstå nödvändiga orsaker / reaktioner (aka inmatningar / övergångar) för galleriet "Nuvarande spelningar" ovan. Förstå nödvändiga övergångar hjälper dig att koda mer självsäker, och det är allt som kodar språkoberoende. Så du kan bestämma kodbibliotek / språk efter att du skapat statligt diagram.

Önskade applikationsfunktioner

Om du tittar på galleriet "Current Gigs" i mitten till vänster om bilden ovan eller på live-sidan ser du att det här är i princip samma begrepp som ett bildgalleri. Klicka på en länk och detaljer om den "spelningen" visas. Men när jag byggde levande sidan fanns det inga jQuery-handledning om hur man slänger text i mixen, för varje "ram" i showcase. Jag var tvungen att komma med min egen kod.

För att göra det måste jag först förstå alla möjliga användarinteraktioner. Ett tillståndsdiagram är idealiskt för detta. Låt oss dock ante. Vad jag verkligen ville ha är ett showcase-område som visar både aktuella spelningar och tidigare spelningar. Det är som en visuell C.V. (Curriculum Vitae, aka "CV"), visar ett galleri av arbetslivserfarenhet. Varje spelkonst innehåller en skärmknapp på den tillhörande webbplatsens hemsida, tillsammans med en del text som ger detaljer om det arbete jag gjorde / gör där.

För nu har sidan bara "Aktuella spelningar", men borde ha "Past Gigs" också. Här är en lista över de funktionella kraven för vad showcaseområdet ska ha:

Tabbed jQuery-gränssnitt, men "osynligt". I stället för att använda vanliga flikar, använd mini-banners som liknar "Current Gigs" -grafen.
När en "flik" klickas (aktuella spelningar, tidigare spelningar) visas den lämpliga spelningslistan tillsammans med rammen (detaljerna) för den första posten.
Standardutställningen är "Aktuella spelningar".
När någon klickar på "Past Gigs", måste listan över tidigare spelningar visa, tillsammans med detaljeringsramen för det första objektet i den listan.
Gigs listor. Varje "flik" kommer att ge en lista över spelningar placerade till vänster med ett Blueprint CSS-nät.
Giglistan är textlänkar.
Varje utställning kommer att ha helt olika länkar (tidigare och nuvarande arbete). Så en "arbetserfarenhet" kan bara visas i en showcase i taget.
När ett objekt i en spelningslista är klickat visas konsertens detaljer "ram". Varje ram visar en skärmsnäpp (tidigare sparad) och den tillhörande jobbeskrivningen. Grunderna för CSS-rutnätet kommer att användas för att placera utställningselementen. (Det här är inte nödvändigt, men det är det jag syftar till.)

Så att upprepa är målet att ha ett flikat gränssnitt där flikarna är märkta "Aktuella spelningar" och "Tidigare spelningar". Detta möjliggör fler flikar senare, begränsad endast av bredden på varje etikett och bredden på presentationsutrymmet (590 bildpunkter). Men jag vill att flikarna ska vara "osynliga", som nämnts. Istället för de typiska flikarna i ett flikgränssnitt vill jag använda mini-banners. Om du tittar på live test sidan finns det en mini-banner med etiketten "Current Gigs", och en annan märkt "Past Gigs". Det blir flikarna. Här är en närbildsskärm av vad det slutliga showcase-området kan se ut, med standardinställningar.

Skapa statsdiagrammet

För att skapa tillståndsdisplayet måste vi först räkna upp alla möjliga unika tillstånd, inmatningar och åtgärder:

Starta tillstånd: Vid laddning av hemsidan:
1. Dölj (ej visad) alla spelkonst med CSS.
2. Nuvarande "Nuvarande spelningar" visas som standard.
3. Inom standardutställningen presenterar du ramen för det första objektet i spelningslistan som standard. Så när någon klickar på "Current Gigs" -fliken, kommer showcase att återställa sig.
Möjliga generiska åtgärder från startstaten:
1. Klicka på "flik". Reaktion / övergång: Gör presentationen som motsvarar fliken klickad.
2. Klicka på ett spelningsobjekt. Reaktion / övergång: Gör motsvarande gig-objektramen.
Möjliga generiska åtgärder från andra stater: exakt samma. Vi är lyckliga i det här fallet, för det här gör statsdiagrammet så mycket enklare.

Obs! Vid denna punkt är vi bara oroade över vad som händer i C.V. monter. I det statliga diagrammet bryr vi oss inte om handlingar som påverkar andra delar av webbsidan. Vi visar bara åtgärder / reaktioner som påverkar C.V. monter.

Här är ett exempel tillstånd diagram för ovanstående funktionalitet.

Några anteckningar om detta diagram:

I denna diskussions syfte är det inte så viktigt vad varje etikett egentligen är. Här representerar var och en en webbplats som jag antingen skriver för tillfället eller brukade skriva för.
Det är inte så komplicerat som det ser ut. Bara fokusera på en övergång i taget och det blir tydligt vad som händer. [Här är åtgärdsetiketterna samma som statens etiketter. Det är inte alltid fallet.] Det är oftast mycket tydligare när du ritar diagrammet själv, lägger till nya statliga cirklar och övergångspilar en i taget.
Övergångar, aka användaråtgärder, representeras av märkta pilar. (Normalt skulle etiketterna vara fulltext, inte de korta formulär som används här.)
Stater, aka reaktioner, representeras av cirklar. Starttillståndet är alltid markerat med en dubbel cirkel och en "S".
Korta former används för båda typerna av etiketter, för att hålla diagrammet mindre rodigt.
Staterna och delstaterna är färgkodade baserat på huruvida de är primära eller sekundära i naturen. Till exempel representerar blå primära tillstånd (och övergångar). Du kan gå från Starta till något blått tillstånd med ett enda klick på lämplig länk. Du kan inte gå till ett lila (sekundärt) tillstånd från Start utan att först gå igenom ett primärt tillstånd.
Eftersom det finns en hel del repetitiv övergång (det vill säga från varje gigobjekt till en annan), visas övergångsgrupper med en av de tjocka skisserade pilarna (blå eller lila fyllning). Till exempel, medan du tittar på FF (FreelanceFolder) spelinformation, kan du klicka på något av spelartiklarna listade för CG (Current Gigs) showcase, inklusive FF själv. Eller du kan klicka på CG "fliken" och återställa showcase. Du kan inte gå från en "nuvarande" spelkonst till en "tidigare" spelkonst, eller vice versa.
Den korta, skisserade blå pilen innehåller övergångar tillbaka till CGs standardläge. Den korta skisserade lila pilen innehåller inte övergångar till PGs standardstatus. (Det beror på att dessa övergångar redan visas exakt. De var inte för CG eftersom diagrammet skulle vara alltför rörigt.)

Genom att expandera på punkt # 5 ovan är tumregeln att om det finns flera repetitiva övergångar från ett relaterat grupp av stater kan du anteckna övergångarna med någon form av kort form. Du vill helt enkelt få en känsla av de viktiga övergångarna så att de är främst i ditt sinne. Ett annat tillvägagångssätt är att ta ett komplext diagram och dela upp i delar: huvudöversikt, sedan "exploderade" versioner av övergångskluster.

Till exempel kan diagrammet ovan ha haft ett huvudstatusdiagram som innehåller noderna S, CG och PG. Då skulle det finnas två detaljerade diagram. Man skulle ha S, CG och motsvarande delstater som representerar olika spelningar. Det andra detaljerade diagrammet skulle ha S, PG och motsvarande gig-deltillstånd.

Slutgiltiga tankar

Sammantaget borde du nu ha en tydligare mental bild av hur showcase-sektionen fungerar. Jag kommer inte att komma in i hur man flyttar från ett statligt diagram till den faktiska koden. Det borde bli uppenbart när du förstår alla användarinteraktioner. Statliga diagram - och din förståelse av dem borde hjälpa dig att skriva mer sammanhängande kod, vilket minskar chanserna för en buggy-applikation. Din kodningsteknik ändras inte.

Koda