Rebuild en 2004-flashwebsted for 2018

I 1999 byggede jeg min første hjemmeside ved hjælp af Web Studio 1.0. Web Studio var en grafisk brugergrænseflade. Det var muligt at oprette en ny LANDING SIDE og træk og slip elementer i den. Jeg oprettede derefter et gratis domæne og hosting med geocities og voila! Jeg havde en hjemmeside. Hurtigt frem til 2004, jeg ønskede at gå videre og så, ligesom mange andre, satte jeg ud til at opbygge en bands hjemmeside.

• 12 Fælles JavaScript spørgsmål besvaret

Meget er ændret siden da. I denne artikel skal jeg tage en tur ned Memory Lane og genskabe det samme websted til internettet i dag.

Få filerne for denne vejledning.

Så lad os starte! For det første starter hvert nyt projekt for mig generelt med MKD efterfulgt af G-initiativ. For dem af jer, der kender mig på et tidspunkt, har jeg sikkert nævnt Dotfiles til dig. Dotfiles er filer, der simpelthen begynder med en prik (det tog mig overraskende lang tid at faktisk gøre den forbindelse!) Og de kan bruges til en række formål. To af mine foretrukne dotfiles er .aliasas og .funktioner. Lad mig uddybe ...

I Bash er det muligt at oprette en ny mappe, der bruger kommandoen Mkdir, da du skal skifte Directory CD i den mappe, som du netop har oprettet. Brug af koden jeg har i mine .funktioner fil, det er nu muligt at køre MKD. Dette vil ikke kun oprette den nye mappe, men har også ændret sig til den pågældende mappe. Dette kan forekomme overkill i starten, men jeg elsker disse mikro vinder. Over tid, især hvis du kører disse kommandoer flere gange om dagen, tilføjer de snart op til en masse gemt tid.

 # Opret en ny mappe og indtast den
funktion mkd () {
    mkdir -p "$ @" & amp; & amp; CD "$ _";
} 

Den næste kommando, hvis du er bekendt med git, er simpelthen GIT init, som gør det muligt for os at udføre projektet. Jeg bruger git meget, selv for indkøbslister! Så snarere end at skulle skrive Git hver gang, tilføjer alias G = "git" til .aliases igen en god, lille tidsbesparende for mig.

Disse dage er der en overflod af forskellige rammer og teknologier. For dette projekt vil jeg gerne holde tingene enkle. Jeg skal bruge HTML, CSS og om nødvendigt et stænk af JavaScript. Først op, lad os oprette den grundlæggende HTML-markup. Men vent! Lad os stoppe og tænke i et øjeblik.

Nogle gange er udviklere, mig selv inkluderet, være super-begejstret for et projekt og ønsker at få cracking straks og gå lige for tastaturet til at skrive kode. Men jeg finder det ofte ikke den bedste tilgang. Jeg elsker at få et overblik i betragtning af projektet først. Ved at gøre dette og have en meget klarere vision om projektet som helhed, finder jeg det giver mulighed for meget bedre beslutningstagning. For eksempel, hvis jeg dykkede direkte ind i koden, kan jeg støde på et problem, som jeg så nødt til at gå tilbage og refactor. Der er et par forskellige resultater med denne tilgang. For det første kan det være, at jeg skal slette koden helt og starte igen; For det andet, hvis jeg fortsætter på denne måde, kan jeg ende med 'spaghetti-kode', hvilket gør det vanskeligt i fremtiden at opdatere, debug og resultere i præstations tab; For det tredje træner det nogle gange okay, og du ender med bedre kode, men jeg ville have tendens til at sige, at det første og andet resultat er langt mere almindelige.

Dette projekt er ret lille; Det har et par sider: Hjem, Nyheder, Gigs, Medier, Album, Links og Fælles Dele Blandt disse sider: Header, Navigation, Typografi Indhold, Lister, Billeder, Videoer. Når det oprindeligt byggede flashstedet i 2004, var tingene meget mere enkle med hensyn til test. Webstedet blev bygget i Flash, til Flash på en stationær computer med en mus og tastatur. Disse dage, mobil og tablet internetforbrug er mere almindeligt end på en stationær computer, og denne tendens fortsætter med at stige.

For at gøre dette til en bedre oplevelse for den, der ser på stedet, skal jeg tage et par ting i betragtning i starten af ​​projektet og bruge en mobil første strategi. For at gøre det, og igen, før jeg skriver en kode, vil jeg komme ud en god gammeldags pen og papir. For det første skriver jeg sitemapet; Dermed er der nogle nøgleområder, jeg tror, ​​kan forbedres. For eksempel bestod mit oprindelige websted af forskellige sider for hvert af bandets album. På det tidspunkt havde de tre albums og så pænt pænt i navigationen. Nu har de meget mere og potentielt mere at komme, så allerede i mit sind tænker jeg på måder at gøre webstedet mere fremtidigt bevis (en oldie, men en goodie er Dan Cederholms BulletProof Web Design. ).

Nu har jeg en grov ide i mit hoved på sitemap og sider, næste gang er at skabe nogle lav-fi-wireFrame. Fra tidligere erfaring med at opbygge mange lydhøre websteder, kommer mobil med interessante designudfordringer, nemlig hvordan man opretter en navigation, men stadig gør det muligt for folk at se hovedindholdet på webstedet. Jeg kommer til at gå sammen med det designresultat, vi alle har vokset til at elske / hader: Burger menuen tilgang. Men jeg vil tilføje et lille twist. De originale kunstværker brugte fugle, så snarere end standard burger menuikonet, jeg vil bruge fugle kunstværk, der vil aktivere menuen og åbne og lukke sine vinger som en måde at angive, om menuen er aktiv eller ej.

Ting i mit sind begynder nu at tage form, med en ide om, hvordan folk vil kunne navigere rundt på webstedet. Jeg skal nu tænke på, hvordan siderne selv kan se ud. Fra starten er det ret simpelt, med typografiindhold. Næste, nyheder - igen typografi indhold, potentielt billeder og derefter en slags navigation for at se ældre indlæg. GIGS - En liste over kommende optagelser med links til købsbilletter. For medier, der ser tilbage på det foregående sted, havde jeg 'Billeder' og 'Videoer' som to forskellige sektioner, men her tror jeg, at der er plads til forbedring og konsolidere som 'medier'. Albums, ah, ja albums - nu er det her, hvor denne slags ting betaler sig. Du ser, albumsiden har typografi og et billede, og skal have brug for en form for navigation for at se ældre indlæg. Lyd bekendt? Lyder meget som den samme struktur som nyhedssiden! At have dette øverste niveau overblik jeg kan se på og tænke på ting på en mere granulær komponent, nogle kunne endda sige Atomic design. niveau, hvis du er bekendt med arbejdet i Brad Frost.

Nu har jeg en ide om, hvordan webstedet skal arbejde på mindre enheder og genanvendelige elementer, det er på tide at gentage processen med større enheder. Da stedet er ret simpelt, og med wireframe'erne, der allerede er oprettet til mobil, ser jeg de større enheder, der er ret lignende - bortset fra nu har vi nogle ekstra rum, så vi kan udvide indholdsområderne og også inkludere en side navigation.

Side navigationen er den bit af webstedet, som fra offset er mest begejstret for. Ved inspiration fra bandets originale kunstværker byggede jeg navigationen som en træ silhuet med blade. Hvert blad var en knap, der var forbundet med en anden side af webstedet. Også, som du rullede ind og svævede fra bladet, ville bladet animere, falde til jorden. Flash var fantastisk til dette; Det blev kaldt Tweening. Du kan indstille et element på en keyframe i grænsefladen på tidslinjen, oprette en anden keyframe længere langs tidslinjen og tilføje en sti for elementet, der skal følges. At tage ting lidt længere, varierer stierne, varigheden og hastigheden af ​​de faldende blade, endte jeg med noget, jeg var meget tilfreds med.

Men nu bruger vi ikke Flash, så hvordan gør vi det her? Ganske ofte vil jeg hoppe til CodePen eller JS bin. For de af jer, der ikke er opmærksomme, er CodePen og JS bin online-tjenester, der gør det muligt for dig at hurtigt kode og gemme. Jeg har tendens til at se CodePen som mere design LED, og ​​JS bin flere JavaScript fokuseret. For dette projekt vil jeg bruge CodePen til at oprette trænavigationen af ​​nogle få grunde. For det første vil jeg begynde at opbygge den vigtigste mobile version af webstedet, og i virkeligheden ved at gøre dette, hvis tingene var tidskritiske, kunne jeg ende med en MVP. Selv om der er forbedringer til det websted, der kunne laves ved at tilføje den dejlige bladnavigation og animation, vil dette tage længere tid at producere. En fordel ved at arbejde i CodePen til trænavigationen betyder, at den er isoleret fra hovedstedet og kodebasen. Hvis tingene bliver vanskelige med at fuldføre det, kan jeg gemme, hvor jeg er hos, fortsæt med hovedstedet, og så kom tilbage til navigationen. Nogle gange finder jeg det ved at gå væk fra et problem, eller endda sover på det, min underbevidsthed kan fortsætte med at tænke på det. Så ved at vende tilbage til problemet, præsenterer en løsning sig selv.

SVGS! Jeg elsker SVG'er. Tidligere i Flash udarbejdede jeg bladaktiver i Illustrator. Utroligt havde jeg stadig en fungerende cd med det originale kunstværk og var i stand til at åbne det. Disse dage bruger jeg skitse, og det gjorde et godt stykke arbejde med at åbne filen. Jeg har nu bladaktiver, som alle er klar til at blive eksporteret som SVG'er. Hvorfor svgs? Der er mange grunde. Hvis vi skulle bruge en JPG eller GIF på en nethinden, ville vi også skulle levere større aktiver, ellers ville de se sløret ud. Også med SVGS kan vi bruge CSS. Dette er fantastisk og lader os simpelthen ændre farven på SVG'en ved hjælp af en smule CSS snarere end at skulle oprette et andet billedaktiv. Det betyder, at det er lettere at opretholde, og som en bonus er det også mere effektivt. Hvis du ikke er bekendt med SVG'er, vil jeg meget anbefale at læse på dem og det utrolige arbejde fra min gode ven, Sara Soueidan. .

Med træ- og bladaktiver nu på plads, er den endelige ting at tilføje, animationen. Der er et par tilgange, jeg kunne tage med dette. Man ville være at forblive tro mod den oprindelige flash path mellem jeg gjorde. Dette ville betyde at replikere stierne og bruge SVG og derefter potentielt yderligere SVG arbejde med stier og animatemotion. Jeg kan godt lide denne ide fra et nostalgisk synspunkt, men CSS er kommet meget gennem årene, og vi har nu omdannet og oversæt til vores rådighed, så det kan være en anden tilgang. At tage ting et skridt videre, kunne vi endda tilføje nogle javascript, der ville randomisere de faldende blade.

Begge muligheder lyder godt, men jeg svinges mod den mere CSS-LED-rute. Her er en anden fordel ved at bruge CodePen, jeg kan hurtigt gå og prøve en tilgang. Hvis det viser sig, at det er mere kompliceret end jeg oprindeligt troede, eller det ikke føles rigtigt, kan jeg prøve en anden tilgang med lidt tid spildt. Faktisk viste det sig for at være en god ide! Jeg kigger stadig på muligheder for dette - henvises til projektet på GitHub for det endelige resultat.

Med Tree Navigation nu sorteret, vendte jeg tilbage til den mobile første tilgang, opbygget navigationen. Hvis du er bekendt med SASS, har du mere end sandsynligt stødt på variabler. Men vidste du, at variabler er nu tilgængelige i CSS? De har Pretty Decent Browser Support I Chrome, Edge, Safari og Samsung Internet også! Da jeg forsøger at holde til grundlæggende CSS og undgå behovet for ekstra afhængigheder, er dette gode nyheder. Så hvordan ville vi implementere dette? Øverst på stilpladen erklærer jeg mine variabler:

: Root {
  - GREY: #CCC;
  - RED: # FB0F0C;
  - grid-størrelse: 10px;
} 

Nu hvor de er erklæret, kan jeg ringe til dem, så for eksempel at sætte kroppens baggrundsfarve ville se sådan ud:

 krop {
  Baggrund: Var (- Grå);
} 

Hvis du tager dette et skridt videre og for at hjælpe med gitterjustering, hvidt rum, lodret rytme, har du måske bemærket, at jeg også har defineret en gridstørrelsesvariabel. Variabler arbejder meget godt med Calc, og det ser lidt ud som sådan:

 // Standardvariabel, der anvendes, udsender 10px.
Padding-Top: Var (- Gitterstørrelse);

// Tilføjelse af calc for at multiplicere variabelenheden med 2, udgange 20px.
Padding-Bottom: Calc (Var (- Gitterstørrelse) * 2); 

Med de mobile navigationsstile komplet, lad os tackle funktionaliteten til at gemme sig og vise den. For TOGGLE-knappen anvender vi en etiketmærke, så i NAV-mærket tilføjer vi en input:

& lt; header class = "header" & gt;
  & lt; h1 klasse = "header_title" & gt; band hjemmeside & lt; / h1 & gt;
  & lt; h2 klasse = "header_currentpage" & gt; Home & lt; / h2 & gt;
  & lt; etiket til = "MobileNav_toggle" klasse = "MobileNav_toggle" & GT; Toggle & LT; / Etiket & GT;
& lt; / header & gt;

& lt; nav klasse = "MobileNav" & GT;
  & lt; input type = "afkrydsningsfelt" ID = "MOBILENAV_TOGGLE" rolle = "knappen" & gt;
  & lt; ul klasse = "mobilenav_list" & gt;
    & lt; li class = "mobilenav_listitem" & gt; & lt; en klasse = "mobilenav_listitemlink" href = "#" & lt; / li & gt;
    & lt; li klasse = "mobilenav_listitem" & gt; & lt; en klasse = "mobilenav_listitemlink" href = "#" & gt; om & lt; / a & gt; & lt; / li & gt;
    & lt; li class = "mobilenav_listitem" & gt; & lt; en klasse = "mobilenav_listitemlink" href = "#" & gt; portefølje & lt; / a & gt; / li & gt;
    & lt; li klasse = "mobilenav_listitem" & gt; & lt; en klasse = "mobilenav_listitemlink" href = "#" & gt; nyheder & lt; / a & gt; & lt; / li & gt;
    & lt; li klasse = "mobilenav_listitem" & gt; en klasse = "mobilenav_listitemlink" href = "#" & lt; / li & gt;
  & lt; / ul & gt;
& lt; / NAV & GT; 

Ved hjælp af følgende CSS kan vi vise og skjule navigationsmenuen; Fordi vi ønsker etiketten i overskriften, kan vi bruge ~ aka tilde eller (U + 007E), så det virker, mens det ikke bliver straks lykkedes af det første element.

 #mobilenav_toggle [type = afkrydsningsfelt] {
  Display: Ingen;
}

#mobilenav_toggle [type = afkrydsningsfelt]: Markeret ~ .mobilenav_list {
  Display: Blok;
} 

Med den mobile navigation komplet, er det tid til at implementere nogle Responsive Web Design . Tilføjelse i hovedindholdet for webstedet, og ved hjælp af det responsive billede i Chrome Developer Tools, kan jeg øge Viewportbredden, indtil jeg føler, at der er nok plads til at holde trænavigationen tilstrækkeligt. Dette ender med at være på 600px, og for dette kan vi bruge en medie forespørgsel:

 .TreenAV {
  Display: Ingen;
}

@media skærm og (min bredde: 600px) {
  .treenav {
    Display: Blok;
  }
} 

Er der næsten! Endelig for trænavigationen til at sidde ved siden af ​​hovedindholdsområdet, skal jeg gøre brug af Flexbox:

 .Container {
  Display: Flex;
}

.treenav {
  Display: Ingen;
  Minbredde: 140px;
} 

Nu tager trænavigationen op 100% højde, med indholdet gør det samme og sidder til højre for det. Det betyder, at uanset hvor længe indholdet bliver, vil det aldrig strømme under trænavigationen. Hvis du gerne vil vide mere om Flexbox, vil jeg anbefale at tjekke ud Flexbox.io af den ene og kun Wes BOS. Der er meget det kan gøre!

Det er alt, hvad jeg har tid til i øjeblikket, men der er stadig masser af ting, vi kunne gøre for at gøre dette projekt endnu bedre. Hvis du har spørgsmål, eller ønsket artiklen, vær venlig at sige hej på twitter. eller til mit websted , eller send mig en pull forespørgsel på GitHub!

Denne artikel blev oprindeligt offentliggjort i udstedelse 304 af net , verdens bedst sælgende magasin til webdesignere og udviklere. Køb problem 304 her eller Abonner her .

Relaterede artikler:

• 5 tips til super-hurtig CSS
• Animere SVG med JavaScript
• Forståelse af CSS Display Ejendom