olshtyn.com - WordPress Prosjekt | WPPoland

#Hvem sitter i den andre enden

olshtyn.com er et byportal for Olsztyn, laget for dem som bor der og for dem som planlegger et besøk. Olsztyn er hovedstaden i Ermland-Masuren, har rundt hundre og sytti tusen innbyggere, flere innsjøer innenfor bygrensen og en turistsesong som tydelig samler seg om sommeren. Prosjektet ble levert i 2010-tallets begynnelse, nærmere bestemt i 2012, omfattet også den visuelle identiteten, og selve utviklingen tok omtrent seks uker.

Det er verdt å begynne med leseren, fordi det er leseren som avgjorde arkitekturen. To personer bruker denne siden på helt ulike måter. Innbyggeren kommer tilbake ofte og blir kort: hun vil vite hva som skjedde i går og hva som skjer i helgen. Den tilreisende kommer én gang, som regel fra mobilen, som regel utenfra regionen, og leter etter det som varer: hva er verdt å se, hvordan kommer man dit, hvor ligger hva. Den første trenger en strøm, den andre en struktur. Et portal som bare leverer strømmen, har et uleselig arkiv etter ett år. Et portal som bare leverer strukturen, gir ingen grunn til å komme tilbake.

Her står det ingen resultattall. Trafikktall tilhører utgiveren av portalen, ikke en prosjektbeskrivelse hos oss. Det som lar seg fortelle ærlig, er hvilke valg som ble tatt og hvorfor, og nettopp det lar seg overføre til neste prosjekt.

#Innholdsmodellen, der arbeidet faktisk lå

Layout og plassering av elementer kom fra kunden. Vår del var å oversette det til maler, responsiv oppførsel og en datastruktur som en redaksjon kan vedlikeholde uten utvikler.

Stoffet i et byportal lever i tre hastigheter. En nyhet har verdi i noen dager og interesserer deretter bare søkemotoren. En arrangementsoppføring er verdifull fram til dagen arrangementet finner sted, og snur så fortegn: den slutter å være en invitasjon og blir et arkiv. En guide til et kulturminne eller en tursti eldes ikke i det hele tatt, og det er den som henter søketrafikk i årevis. Standard WordPress legger alle tre i samme bøtte sortert på dato, noe som betyr at det mest varige forsvinner raskest ut av synsfeltet.

Derfor finnes tre innholdstyper: nyheten, arrangementet med dato og sted, og guidestoffet uten utløpsdato. Konsekvensen vises først etter et driftsår. Et avsluttet arrangement faller av oversiktene av seg selv, i stedet for å henge der til noen husker å fjerne det. Guidestoffet konkurrerer ikke lenger med dagens nyhet om plass, så ingen trenger å skyve det oppover med en kunstig oppdatert publiseringsdato hver måned. Redaksjonen svarer på spørsmålet om materialtype én gang, når saken opprettes, i stedet for å overvåke synligheten ukentlig.

Taksonomien ble holdt bevisst smal. Den fristende modellen beskriver alt langs alle akser samtidig: bydel, tema, hendelse, person, sted. Den ser fleksibel ut på lanseringsdagen og faller fra hverandre i måned seks, fordi to redaktører plasserer samme sak ulikt og arkivet slutter å la seg filtrere. Kategorisettet er kort og lukket, mens det som virkelig er bevegelig ligger i frie stikkord som ingen navigasjon bygger på.

Adressene ble behandlet som en langsiktig verdi. Adressen til en sak inneholder den lesbare tittelen, uten dato og uten tallkode, og kategorien er ikke del av stien. Kategorier blir omorganisert før eller siden, og å endre adressen på en tekst publisert for et år siden koster posisjon og krever en videresending. En adresse som ikke avhenger av redaksjonelt ryddearbeid, overlever en omorganisering gratis.

#Hurtigbuffer i en publikasjon som må være synlig straks

Teknologien er WordPress på PHP med MySQL, Redis og Memcached som hurtigbuffer, et CDN foran, samt HTML5, CSS3, SASS og JavaScript på klientsiden. Koden ligger versjonert i Git, og utvekslingen med grensesnittet går over AJAX og REST-endepunkter.

Sammenlignet med en nettbutikk har et nyhetsportal en stor fordel: nesten hver visning er lik for alle besøkende. Det finnes ingen handlekurv, ingen kundespesifikke priser, ingen økt som lekker inn i siden. Dermed kan de aller fleste sidevisningene leveres uten at PHP starter i det hele tatt. Det vanskelige er ikke bufringen, men invalideringen.

Tidsbasert utløp er feil verktøy her. Setter man den lang, ser ikke redaksjonen sin egen artikkel og krever at bufferen slås av, gjerne i årets travleste time. Setter man den kort, hjelper bufferen ikke lenger akkurat når den trengs. Invalideringen er derfor knyttet til en hendelse i stedet for til en klokke: lagring av en sak tømmer forsiden, de berørte kategorilistene og saken sin egen adresse, mens resten av nettstedet forblir urørt. Publiseringen blir utløseren, redaksjonen ser resultatet med én gang, og ingen trenger å utvide rekkevidden til hele nettstedet.

Redis og Memcached har ulike oppgaver. Objektbufferen forkorter spørringene som hver forespørsel uansett betaler for, altså menyer, kategorilister og de tyngre arkivspørringene. Flyktige data som ikke må overleve en omstart, ligger for seg selv. Denne delingen har en driftsmessig nytte: å tømme objektbufferen under en feilsituasjon logger ingen ut av redaksjonsgrensesnittet.

CDN-et er det tredje laget, og det betyr mest for den tilreisende leseren. Den som leser fra en annen by eller fra mobilen på roaming, får statiske filer fra en node i nærheten, og applikasjonsserveren ser aldri de forespørslene. For bildetungt guidestoff er det den største enkeltbesparelsen i hele leveransen.

#Etterlasting, kart og bilder

Nyhetslister henter flere oppføringer asynkront gjennom AJAX og egne REST-endepunkter i stedet for å laste siden på nytt. Gevinsten er åpenbar, kostnadene er to, og i 2012 var begge lette å overse. Den første gjelder synlighet for søkemotorer: innhold som først dukker opp etter et klikk, kan være usynlig for en robot, så den første porsjonen av enhver liste ligger i sidekildekoden, mens etterlasting bare gjelder påfølgende sider. Nummerert sidenavigasjon står igjen i markeringen selv når grensesnittet ikke viser den, fordi den er veien for roboten og for enhver besøkende uten JavaScript. Den andre kostnaden gjelder bufferen: et endepunkt som returnerer et listeutsnitt er en egen adresse, og enten har det sin egen bufferpolitikk, eller så blir det hullet der topptrafikken renner inn i PHP.

Kart følger samme resonnement. Et kart fra en ekstern leverandør er noen hundre kilobyte skript pluss en forbindelse til en fremmed tjener, betalt uansett om noen ser på kartet. Det lastes først når den besøkende faktisk kommer til seksjonen med stedet, og fram til da står et statisk bilde med adressen der. For en mobil leser som står i gata og skal sjekke én ting, avgjør den forskjellen om siden i det hele tatt rekker å åpne seg.

Bildene fortjener en egen setning, for i et byportal utgjør de mesteparten av de overførte bytene. Redaksjonen publiserer rett fra kameraet, i en størrelse som er mange ganger større enn noen visning på nettstedet. Behandling ved opplasting lager varianter for listen, for saksvisningen og for galleriet, og malen forteller nettleseren hvilken variant som gjelder ved hvilken skjermbredde. Uten det laster mobilleseren et bilde laget for en skjerm, betaler for det med data og tid, og redaksjonen får aldri vite det, fordi alt går fort på deres linje.

#Arkivet som var eldre enn nettstedet

Deler av stoffet kom fra tidligere versjoner av tjenesten og måtte flyttes med historikken intakt. Import fra arkiverte kopier, blant annet fra Web Archive, ser ut som en times arbeid og tar flere dager, alltid av de samme grunnene.

Eldre nettsteder brukte annen tegnkoding, så polske diakritiske tegn kommer tilbake fra en import som byggrøt, synlig først når noen faktisk leser det aktuelle avsnittet. Gamle adresser har en annen form enn nye, så hver importert sak trenger en videresending fra sin tidligere adresse, ellers kaster nettstedet bort alle innkommende lenker og alle posisjoner det har bygget over år. Arkiverte bilder er ofte ufullstendige, og bildetekstene ligger inne i brødteksten i stedet for i et eget felt.

Rekkefølgen var avgjørende: først kartlegging av gamle adresser mot nye, så import av innholdet, til slutt manuell kontroll av en stikkprøve på en kopi av produksjonen. Motsatt rekkefølge ender i en ny import, fordi å rette adresser etter lansering betyr at en del av trafikken allerede har landet i ingenting.

#Merket skal fungere i en topplinje

Prosjektet omfattet også den visuelle identiteten, og merket ble tegnet for stedet der det faktisk lever. En portallogo tilbringer mesteparten av tiden i en topplinje på noen få titalls piksler, på en telefon, ved siden av en menyknapp, og den må være gjenkjennelig også som ikon i en nettleserfane. Det snur kravene sammenlignet med et merke for trykk: lesbarhet i liten skala, oppførsel på ensfarget bunn og en forenklet variant som ikke faller fra hverandre ved et titalls piksler bredde. Et rent horisontalt merke med fine detaljer ser bra ut i en presentasjon og forsvinner i en ekte topplinje, så variantene ble laget sammen med malene og ikke før dem.

#Drift, vedlikehold og én regel om utvidelser

Et nyhetsnettsted har ingen hviletilstand, så vedlikeholdet ble planlagt sammen med utviklingen og ikke etterpå: oppdateringer av kjerne, tema og utvidelser, gjennomgang av systemlogger, sikkerhetskopier der gjenopprettingen faktisk er prøvd og ikke bare satt opp, og små funksjonelle endringer som følger av hvordan redaksjonen virkelig arbeider.

Én regel bør sies rett ut. Sikkerhet løses her i kode og i serverkonfigurasjon, ikke med enda en sikkerhetsutvidelse. En slik utvidelse kjører inne i PHP, altså etter at forespørselen allerede har startet applikasjonen, den blir jevnlig selv en sårbarhet, og den koster noe på hver eneste forespørsel. For et portal med ujevn trafikk som må tåle et utslag den dagen noe skjer i byen, er det en dårlig bytte. Filtrering ved inngangen, rettighetskontroll i koden og en stram serverkonfigurasjon koster mindre og virker tidligere.

Kommentarmoderering ble en egen post i vedlikeholdet. Diskusjonen under lokalnyheter er den mest levende delen av et byportal og den som oftest trenger et menneske som leser ordentlig. Redaksjonen fikk moderasjonsverktøy og en kø for tilbakeholdte innlegg, ikke en automat.

Å fjerne en kommentar i en kommunal sak er en redaksjonell og ikke en teknisk avgjørelse. Et automatisk filter ville vært billigere i drift og tatt feil nettopp i de sakene det gjelder, altså der en innbygger anklager kommunen for noe.

Testingen før lansering gikk mot en kopi av produksjonen og ikke mot en tom installasjon, for en tom installasjon har ti saker, hver liste får plass på én skjerm, hver spørring er øyeblikkelig og et arkiv finnes ikke. Problemene i et portal begynner ved noen tusen oppføringer, når kategorisider blir tregere, det interne søket gir ubrukelig sortering og sidenavigasjonen når side tjue, som ingen åpnet under testing. En produksjonskopi viser alt dette på noen minutter.

#Oppsummering og det analysen slo fast

Neste portal begynner med spørsmålet om hvem som leser det og hvor ofte, og først deretter med hva som skal ligge i databasen. Her fikk det første spørsmålet to svar i stedet for ett. Innbygger og tilreisende vil ha ulike ting fra den samme forsiden, og analysen tok det til etterretning i stedet for å slå dem sammen til én tenkt leser. Omfanget fulgte av det og dekket innholdsforvaltning, arrangementskalender, stedskart, gallerier og kommentarer.

Tidsplanen ble delt i etapper, slik at redaksjonen kunne begynne å fylle nettstedet før de siste arbeidene var ferdige. Referansene kunden pekte på, var portaler med sterkt lokalsamfunnspreg, og derfor havnet kommentarer og arrangementer høyt mens dekorative lag havnet lavt. Til et neste prosjekt overføres det tekniske laget og måten å resonnere om hurtigbuffer for redaksjonelt innhold på. Innholdsmodellen overføres ikke, fordi den ble skrevet for én by, én redaksjon og én publiseringsrytme.