Media & Publishing: mavicon.pl

#mavicon.pl, en moderne nettside som presenterer innovative løsninger

En del av arbeidet med en bedriftsnettside består i å la være å bygge ting, og den delen dukker nesten aldri opp i prosjektbeskrivelser, selv om den er like mye en beslutning som enhver funksjon som faktisk ble laget. Derfor står den her først.

Det finnes ingen priskalkulator. Omfanget av disse tjenestene følger av en gjennomgang og ikke av en parameterliste, og en kalkulator ville produsert et tall som ingen senere bekrefter. Et ubekreftet tall på en tilbudsside koster mer enn det gir: det skaper henvendelser med feil forventning og tvinger den første samtalen til å begynne med en korreksjon.

Det finnes ingen teller over gjennomførte prosjekter. Slike tall lever sitt eget liv. Etter et år husker ingen hva som ble regnet med, om små vedlikeholdsoppdrag telte, eller fra hvilket tidspunkt tellingen startet, og et tall der opprinnelsen ikke lenger lar seg rekonstruere, er verdiløst som dokumentasjon.

Det finnes heller ingen automatisk innhentet nyhetsstrøm fra bransjen. Slike moduler eldes dårlig. De ser levende ut den første måneden og ut som en forlatt bygning i tredje år, fordi kilden har endret formatet eller er slått av. Et tomt felt på en bedriftsside sier mer om leverandøren enn innholdet som en gang sto der.

Fellesnevneren for de tre utelatelsene er den samme: hver av dem ville sett bra ut ved lansering og blitt en forpliktelse over tid. Et bevisst fravalg er her et fullverdig arbeidsresultat og ikke et hull i leveransen.

#nøkkelfunksjonaliteter og benyttede teknologier

Et selskap som selger tekniske løsninger har det motsatte problemet av en nettbutikk. Butikken viser et produkt og en pris, og den besøkende vet på sekunder om det passer. En teknisk leverandør selger noe som ikke lar seg fotografere, til en kjøper som som regel ikke klarer å sette ord på sitt eget problem ennå. Vedkommende kommer med et symptom, ikke med en bestilling.

Hele innholdsmodellen følger av det. Tilbudet må kunne leses fra symptomsiden, ikke bare under navnet på tjenesten, for den som har et uutholdelig tregt lagersystem, søker ikke etter teknologien som burde skiftes ut. Referanseprosjekter gjør mer arbeid enn tjenestebeskrivelser, fordi de lar en leser kjenne igjen sin egen situasjon i en annens. Og siden må tåle å bli lest av en teknisk person som sjekker om leverandøren vet hva han snakker om. På den prøven stryker generelle formuleringer umiddelbart og varig.

Innholdsmodellen skiller derfor tre ting som en vanlig bedriftsside holder samlet: tjenestebeskrivelsen, beviset i form av et gjennomført prosjekt, og det forklarende stoffet om temaet. Hver av dem har sin egen leser, sin egen oppdateringsrytme og sin egen plass på veien mot en henvendelse. WordPress med egne innholdstyper bærer den oppdelingen. Den lønner seg først etter et par år: den første måneden ser den ut som unødvendig kompleksitet, fordi kategorier gjør samme nytten. Etter to hundre oppføringer er forskjellen at en endring i prosjektmalen ikke berører bloggen, og at en redaktør som legger inn en tjeneste, møter et skjema med feltene en tjeneste faktisk har, i stedet for et universelt tekstfelt med instruksjonen skrevet i en kommentar.

Presentasjonsmodulene henter innhold uten å laste siden på nytt. Baksiden nevnes sjelden, så den bør nevnes: innhold som hentes i etterkant, er innhold en søkemotor kanskje aldri ser, og på en side hvis eneste oppgave er å skaffe henvendelser fra søk, er det en forretningsmessig og ikke en teknisk avveining. Løsningen ble at navigasjon, filtrering og flere listesider hentes asynkront, mens selve brødteksten på en tjenesteside aldri gjør det. Første skjermbilde er komplett i dokumentkilden.

Kontaktskjemaet validerer både i nettleseren og på serveren og ruter henvendelser til riktig avdeling. Dobbeltarbeidet er ikke sløsing. Validering i nettleseren finnes for at ingen skal vente på et serversvar for å få vite om en skrivefeil. Validering på serveren finnes fordi den første kan omgås, og et kontaktskjema uten den er rett og slett en åpen dør for roboter.

#det teknologilisten ikke sier

Verktøylisten lenger nede beskriver siden slik den står etter mange år med vedlikehold, ikke stacken den ble lansert med. Den forskjellen er viktig nok til å sies rett ut.

Prosjektet gikk i luften i 2012. Det var WordPress uten REST API i kjernen, uten blokkredigering, med egne innholdstyper som var to år gamle, og med responsivt oppsett som så vidt hadde sluttet å være en nyhet. React ble ikke offentliggjort før i 2013. REST API kom inn i WordPress-kjernen i versjon 4.7 mot slutten av 2016. Tailwind CSS ble laget i 2017, og PHP 7 kom i 2015, slik at flyttingen bort fra 5.x-grenen var en egen vedlikeholdsoppgave flere år etter lansering og ikke en beslutning tatt under utviklingen.

Prosjektbeskrivelser presenterer rutinemessig dagens tekniske lag som det opprinnelige, og resultatet er at ingen kan skille en designbeslutning fra en senere utskiftning framtvunget av tidens gang. På et prosjekt som er vedlikeholdt i over ti år, er den andre typen i klart flertall.

#utfordringer og programmeringsløsninger

Dynamisk innhold krevde egne endepunkter. Uten REST API i kjernen betydde det et håndskrevet inngangslag med egen rettighetssjekk og eget svarformat. Det arbeidet eldet raskere enn noe annet i prosjektet, og nettopp det er lærdommen: kode som skrives fordi plattformen mangler noe, er den første slettekandidaten den dagen plattformen får det. Alternativet, å drive en egen løsning ved siden av kjernen, krever husleie ved hver eneste oppdatering.

Ytelsesarbeidet hvilte på caching i flere lag med Redis og Memcached, komprimering av ressurser og levering gjennom CDN. To cacher i én installasjon høres ut som overflod inntil man ser at de betjener forskjellige ting, den ene en objektcache for databasespørringer, den andre sesjoner og fragmenter av visninger. Gevinsten fra en objektcache er likevel mindre på en markedsføringsside enn det som gjerne antas, fordi mesteparten av trafikken er anonyme besøkende på et dusin sider, og de kan betjenes billigere ved å levere hele siden fra cache og aldri gå ned i PHP.

Integrasjon mot eksterne systemer omfattet toveis utveksling med CRM og analyseplattformer. Det avgjørende spørsmålet var oppførselen ved feil. De fleste utvidelser viser som standard en feilmelding eller en tom seksjon, noe som på en salgsside ser ut som at hele nettstedet er nede. Her har hver forbindelse en reserveverdi: det sist kjente svaret, og når heller ikke det finnes, en statisk utgave av seksjonen. Den besøkende ser da en side uten én modul, ikke en feilmelding.

Flyttingen av innhold fra arkiverte utgaver av siden brukte import- og eksportverktøy sammen med Web Archive. Der ligger en felle som først blir synlig etter publisering: arkivet bevarer teksten, men ikke adressene teksten var indeksert under, og heller ikke bilder som ble lastet fra fremmede domener. Uten å gjenskape de gamle adressene som videresendinger ser migreringen vellykket ut og sletter samtidig hele nettstedets historikk i søk.

#hvor tiden faktisk går på en markedsføringsside

Diskusjonen om hastighet på en bedriftsside ender nesten alltid i minifisering og bildekomprimering, altså i de ti prosentene et måleverktøy viser. Den reelle kostnaden ligger andre steder og er nesten identisk på tvers av WordPress-prosjekter i denne klassen.

Den første posten er antall databasespørringer per forespørsel. En mal som bygger meny, prosjektliste og seksjonen for relaterte tjenester med separate spørringer inne i løkker, produserer flere titalls der tre ville holdt. På en tom installasjon ser man ingenting, fordi hver tabell har en håndfull rader. Etter to år med publisering er forskjellen tydelig og viser seg som generell treghet uten én identifiserbar årsak, altså den vanskeligste sorten ytelsesproblem.

Den andre posten er ressurser som lastes globalt. En utvidelse for kontaktskjema legger som standard stilarket og skriptet sitt på hver eneste underside, også de uten skjema. Galleriutvidelsen gjør det samme, og det gjør slideren også. Til sammen blir det noen hundre kilobyte ingen noen gang bruker, og ingen av dem ser skyldig ut alene.

Den tredje er den minst åpenbare og gjelder fremmede skript. Analyseverktøy, chat og annonsepiksler kommer inn gjennom kode limt inn i sidehodet og faller dermed utenfor all versjonskontroll. Et avbrudd hos leverandøren av et slikt skript kan blokkere gjengivelsen av en side der ellers alt er i orden, og feilsøkingen starter i egen kode, fordi ingen husker en linje limt inn et år tidligere.

#verktøy og teknologier

WordPress er fortsatt grunnlaget, fordi kunden kan redigere innhold uten utvikler, og på en markedsføringsside slår det kriteriet alle andre. PHP og MySQL bærer serverlaget. HTML5, CSS3, SASS og JavaScript utgjør presentasjonslaget, og SASS fortjener plassen sin ikke gjennom kortere skrivemåte, men gjennom at merkevarefargen har ett sted i stedet for førti. Bootstrap og Tailwind CSS gjør det raskere å bygge et enhetlig oppsett, med forbeholdet over om når hver av dem kom inn i prosjektet.

Redis og Memcached holder mellomlagringen, Git holder koden. Versjonskontroll blir i prosjekter av denne størrelsen noen ganger regnet som en formalitet, og det er omvendt: det er den eneste mekanismen som lar en hastig rettelse rulles tilbake uten gjetting om hva som faktisk ble endret.

#support og vedlikehold av WordPress-siden

Den løpende oppfølgingen omfatter respons på tekniske problemer og retting av feil etter oppdateringer, jevnlige oppdateringer av kjerne, tema og utvidelser, gjennomgang av logger, sikkerhetskopiering etter plan, og mindre funksjonelle og visuelle justeringer etter hvert som virksomheten trenger dem.

Ett punkt der fortjener utdyping, fordi det står bak de fleste hendelser på nettsteder av denne typen. En oppdatering av en utvidelse ødelegger sjelden et nettsted av seg selv. Den ødelegger det når temaet har overstyrt oppførselen til den utvidelsen ved å lene seg på en implementasjonsdetalj forfatteren aldri lovet å beholde. Derfor går oppdateringer først til et testmiljø som er en kopi av produksjon og ikke en tom installasjon. På en tom installasjon med standardtema virker alt, og testen sier ingenting om hva som skjer i produksjon.

Sikkerhetskopier får verdi først når noen faktisk har gjenopprettet fra dem minst én gang. En sikkerhetskopi som aldri er tilbakeført, er en hensiktserklæring og ikke en sikring, og forskjellen mellom de to oppdages alltid i det verst tenkelige øyeblikket.

#oppsummering og foreløpig analyse av kundekrav

Den innledende analysen slo fast flere punkter som ble grunnlaget for prosjektet. Målet var å bygge selskapets posisjon som leverandør av avanserte løsninger og å tiltrekke kunder som er interessert i slikt arbeid. Kravene omfattet dynamisk presentasjon av tilbudet, integrasjon mot eksterne systemer og et fleksibelt publiseringssystem. Omfanget dekket modernisering av sidearkitekturen, responsive visninger og presentasjonsmoduler. Prosjektet ble delt i etapper, slik at funksjoner kunne lanseres gradvis. Kunden pekte på referansenettsteder med tydelig presentasjon av tilbudet, og det formet resultatet.

I ettertid er det siste punktet det mest interessante. Referanser oppgitt av kunden behandles vanligvis som materiale til et moodboard. I praksis bærer de informasjon om noe helt annet enn estetikk: de forteller hvilken rekkefølge kunden regner som naturlig når et tilbud leses, hvor vedkommende venter å finne en pris, og hvor kontaktinformasjonen skal stå. Det er beslutninger om innholdsmodellen og ikke om utseendet, og de overføres til senere prosjekter langt bedre enn noe oppsett gjør.

Nettstedet ble bygget som et markedsføringsverktøy med tydelig struktur på tilbudet, plass til referanseprosjekter og grunnlag for videre innholdsarbeid. Det som bæres videre herfra, er arbeidsmåten: innholdsmodell før mal, tester mot en kopi av produksjon, og en klar grense mellom det som hører hjemme i dokumentkilden og det som kan komme etterpå. Selve stacken bæres ikke videre, for halvparten av en stack fra 2012 ser annerledes ut i dag, og det er tingenes normale gang og ikke en svakhet ved prosjektet.