Senikk.com snakker om problemer med kommentar- og trackbackspam, noe jeg heldigvis har kvittet meg med.

Det var trackbackspam som jeg måtte sloss lengst med. Jeg tenkte å innføre manuell validering, altså godkjenning, av alle trackbacks, men i den prosessen begynte jeg å studere trackbackpingene litt. Det som plutselig slo meg, er at stort sett alle reelle trackbacks kommer fra samme nett som serveren det tilbaketråkkes til befinner seg i, mens dette aldri er tilfellet for spammerne.

Så det jeg gjør, er at jeg godkjenner trackbacks automatisk dersom de første to oktettene av IP-adressen er lik i adressen som sender trackbackpingen, og i IP-adressen til URL’en det skal linkes til. Dersom de to ikke stemmer overens, settes trackbacken til godkjenning. Hittil har jeg ikke hatt en eneste feil i noen retning med dette systemet.

Kanskje litt skummelt å poste det her, i tilfelle noen av de store systemene fanger det opp. For da vil sikkert spammerne finne en vei rundt det. Men, men – vi får være glade for de slagene vi vinner i krigen mot spammerne.

Etter hvert har jeg opparbeidet meg en viss erfaring med web generelt og publiseringssystemer spesielt, og hvordan disse møter organisasjoner. Her skriver jeg om dette, og hva en organisasjon bør være oppmerksom på når de skal kommunisere via web. Denne artikkelen er på ingen måte tenkt som noen fasit, den er muligens ikke en gang ferdig. Konstruktive kommentarer mottas derfor med stor glede.

Den spede begynnelsen

Jeg har drevet med produksjon og implementering på web i noen år, og da jeg begynte, handlet det om hjemmesider. En kul side på webben som en kunne be kunder, venner og andre forbindelser se på. Og det gjorde de. Underholdningsverdien var langt viktigere enn informasjonen, uansett hvilken bransje man tilhørte, og dess flere effekter man greide å putte inn i en side, jo bedre var det. Det var svært viktig å vise at man kunne bruke alle de nyeste taggene som nettleserprodusentene hadde funnet opp som våpen i den store nettleserkrigen, mens ord som «standardkonform» og «tilgjengelig» var fullstendig fremmede. Det var en tid som ga mange morsomme websider, og som nok var viktig for å gjøre webben populær, men det var nok store ressurser som gikk til veldig lite i denne perioden.

Webutvikling i denne tiden var preget av lystmetoden. En eller annen i organisasjonen syntes web var spennende, og hadde lyst til å lage en webside. Eller det var noen som hadde en nevø som gikk på universitetet og kunne det her med Internett, og gjerne ville lage en webside hvis noen betalte en sydentur først.

Dette var begynnelsen på en lang periode hvor mange lærte veldig mye, ikke minst om hvordan man ikke skal produsere materiale for web. Dette førte til at man tenkte på nytt, og etter hvert så behovet for å gjøre ting slik Tim Berners-Lee i utgangspunktet hadde ment. Strukturert, validerende koding, tilgjengelighet og skille mellom presentasjon og struktur ble nye moteord, og HTML 4, CSS og stadig bedre nettlesere gjorde dette gjennomførbart. Les mer om dette i Wilhelm Joys Andersens glitrende foredrag «Vevutvikling med åpne standarder». Men det skjedde mye før vi kom så langt.

Et av problemene med mangelen på standardkonformitet ved nettsidene som ble produsert i webbens barndom viste seg når man skulle oppdatere eller legge til informasjon. Nettstedets struktur og tekniske løsning var ikke tilpasset dette, og mangelen på konsekvent oppmerking gjorde at de forskjellige oppsettene som florerte i det vi kanskje kan kalle første generasjon av webutviklingen ikke snakket særlig bra sammen.

WYSIWYG-editorene kommer

Dette ble forsøkt løst med verktøy som AOLpress, Mozilla Composer og Frontpage, i noe som da blir andregenerasjons webutvikling. Denne generasjonen preges av at man nå hadde skjønt at nevøen som kom hjem fra syden kanskje ikke var den rette til å styre bedriftens websatsning likevel, men at man selv måtte ha litt kontroll med hva som fantes der ute, og dermed kjøpte eller lastet ned et slikt verktøy til en eller annen ansatt man mente burde ha ansvaret for dette.

Disse verktøyene skulle la hvem som helst editere og oppdatere websider i verktøy basert på WYSIWYG uten tanke på underliggende teknologi, og uten det minste kjennskap til HTML. Denne måten å angripe problemet på viste seg ikke som den beste når det kommer til organisasjoner med et informasjonsbehov, og disse verktøyene løste heller ikke utfordringene man hadde møtt i «forrige generasjon» godt nok.

Verktøyene hjalp ikke brukerne med å strukturere websidene sine. Malfunksjonene som skulle sikre enhetlige uttrykk gjennom organisasjoner ble sjelden brukt etter intensjonene, og friheten til å gjøre hva som helst, gjorde at mange gjorde veldig mye rart. Jeg husker for eksempel en firmaside hvor absolutt alt innhold blinket taktfast.

De forskjellige programmene fungerte heller ikke om hverandre, av og til ikke engang fra versjon til versjon. Koden de produserte holdt ikke noen særlig kvalitet med mindre brukeren var svært dyktig, og de hadde gjerne for mye funksjonalitet, slik at brukerterskelen ble for høy for ikke-tekniske brukere, mens programmene på den andre siden ofte hadde for få muligheter og utgjorde en tvangstrøye for de som hadde jobbet en del med web, og ville beholde kontrollen selv.

Publiseringsverktøyene møter kravene i tiden

Neste generasjonsskifte kom med et forsøk på å møte denne utfordringen, og det var med publiseringssystemenes fremvekst. Med et publiseringssystem forstår jeg her et oppsett hvor teknologien bak en web skilles fra det å produsere innhold til den, og hvor presentasjonen av innholdet bestemmes av systemet. Slike publiseringssystemer gir programmerere og webkodere mulighet til å arbeide med det de er gode på, grafiske designere kan få leke seg med former og farger ut fra visse kriterier satt i maler, og forfattere kan fokusere på innhold framfor fontfamilier. Organisasjonen kan sikres et helhetlig ansikt eller uttrykk utad, og både grafisk profil og innhold kan oppdateres og endres uten behov for å bygge om hele webben. Gode publiseringssystemer gir også god struktur på websidene, søkbarhet og tilgjengelighet. Dette er løsninger som i praksis gjør bruk av de mulighetene strukturert koding med skille mellom presentasjon og innhold har gitt oss.

Webpubliseringssystemer har selvfølgelig eksistert lenge, for eksempel har nettaviser vært tidlig ute med slike, men generasjonsskiftet kom når de ble allemannseie, både gjennom salg av ferdige pakker som ikke måtte utvikles for hver enkelt organisasjon, og gjennom åpne, fritt tilgjengelige løsninger hvem som helst kunne installere og bruke på sin egen webhotellkonto.

Framveksten av publiseringssystemer startet også bloggeeventyret, bloggetjenester som blogg.no og Blogger.com er ikke annet enn små, personlige webpubliseringssystemer. En wiki er et annet slikt system som har gitt oss for eksempel Wikipedia.

Etter min mening, er fremveksten av publiseringssystemene det mest produktive som har skjedd med webben. Da jeg begynte som blogger, var det store flertallet av norske bloggere teknisk orienterte. Vi var i utgangspunktet kanskje vel så opptatt av å utvikle publiseringssystemet vårt som å faktisk bruke det, til å kommunisere. På de snart fire årene som har gått, har dette forandret seg totalt. Nå skriver snart alle sammen om alt mulig, fra blomster til motorsykler. Det kan av og til virke som for mye av det gode, men jeg tror ikke det. Gode søkeverktøy og aktiv linking mellom mennesker som på den måten kvalitetssikrer hverandre, gjør at vi greier å skille vekk det uvesentlige.

Publiseringssystemer i organisasjoner

Men minst like viktig som bloggene er for uttrykkstrengte privatpersoner, ble publiseringssystemene for organisasjoner. Gode publiseringssystemer lot organisasjonen dra flere mennesker inn i informasjonsarbeidet. Informasjon kunne legges ut raskt, uten behov for noen behandling hos teknisk personell, og informasjon ble oppdatert med et tastetrykk. Web ble en kanal hvor teknologien ble av underordnet interesse for den som faktisk skulle kommunisere et budskap. Informasjonen ble det vesentlige – slik som den før nevnte Tim Berners-Lee tenkte det.

Slik jeg ser det, er det omtrent der vi er nå. Nyhetsmatinger i RSS og Atom har gjort fokuset på innhold enda viktigere, søkemotorene har fått en langt enklere jobb med indeksering etter som koden har blitt strukturert, og nye enheter som mobiltelefoner, multimedie-Tver og PSP-maskiner nyter godt av god koding. Vi har mange godt fungerende verktøy til informasjonsarbeid, og flere organisasjoner blir stadig flinkere til å bruke dem. Alt ser bra ut. Nesten.

Utfordringer med publiseringssystemene

Faren med publiseringssystemer ligger i det at man gjør seg for avhengige av dem. Informasjonen ligger i systemet, det er bra. Men hva om man ønsker å bruke informasjonen på en ny måte? Hva om man har kjøpt et publiseringssystem fra en leverandør, men ønsker å gå over til en annen, vil det være problemfritt å ta med seg informasjonen? Er dette kontraktfestet på noen måte? Det som er lagret i systemet, er som oftest lagret i en eller annen database. Finnes det dokumentasjon på dette formatet, og har organisasjonen mulighet til å hente ut dataene fra databasen i et format egnet for datautveksling?

Kort sagt: Hvem kontrollerer i realiteten organisasjonens informasjon?

Dette er viktig – av mange grunner. Den klareste er selvfølgelig at kontroll over informasjonen er nødvendig for å kunne sikre at riktig informasjon blir gitt. Hvis en leverandør av en eller annen grunn mislykkes i å gjøre jobben sin, må man ha mulighet til å ta med seg informasjonsdatabasen til en annen leverandør. Hvis alternativet er å bygge opp alt på nytt, har man plutselig egentlig ikke kommet særlig mye lengre enn i andre avsnitt av denne artikkelen. Og man må ha mulighet til å selv sikkerhetskopiere informasjonsbasen sin, slik at man ikke sitter med skjegget i postkassa ved force majeure.

I tillegg er det et økonomisk aspekt. Hvis man låser seg til et lukket system uten gode nok kontraktsforhold, risikerer man det en organisasjon (som skal få være uidentifisert) som ønsket en RSS-feed av nyhetssakene sine kom ut for – de ble presentert for en regning på 15.000 for noe som neppe var mer enn fire timers arbeid, og som kanskje burde vært en del av pakken i utgangspunktet. Men ny teknologi vil alltid kunne stille nye krav. Muligheten til å hente inn tilbud på utvidelser og omarbeiding uten å måtte begynne på nytt med et helt nytt publiseringssystem, burde være like selvfølgelig som muligheten til å endre på en nyhetssak uten å ringe en tekniker.

Noen høyttenkte tips:

Tredjegenerasjons webutvikling gir organisasjonene muligheten til å ta eierskap over informasjonen sin, men det krever at de faktisk gjør det. Det er mange utfordringer knyttet til det, og intensjonen min med denne artikkelen, har ikke på noen måte vært å prøve og belyse alle disse. Men jeg vil likevel slutte av med en liten sjekkliste over noen av de aspektene en organisasjon som skal implementere en publiseringsløsning bør tenke på:

• Definer informasjonen. Hva trenger man å lagre i databasen? Hvordan vil en typisk sak se ut? snakker man om kun ren tekst, eller masse bilder, lydklipp og multimedia? Og hvordan vil det gå hvis vi om et år ombestemmer oss med tanke på dette?
• Hvordan skal informasjonen presenteres? «Enn utskriftsvennlig versjon, da?» er det spørsmålet som oftest dukker opp dagen etter at man har lansert første utgave av en ny web. I tillegg har jeg nevnt mobiltelefoner og PSP, jeg har nevn RSS og Atom-matinger—og det er bare det jeg kommer på akkurat nå. Hva med det jeg ikke kommer på, og hva med det vi ennå ikke vet hva er? Systemet må kunne presentere informasjonen slik vi til enhver tid behøver. Validerings- og WCAG-krav spiller også inn her.
• Søkemuligheter blir som oftest også føyd til helt til slutt i en prosess, og vil derfor ofte fremstå som litt av et stebarn. Prøv søkemuligheten i din favoritt-web-avis for å se hva jeg mener. Definer krav til søkbarhet med en gang, det er en av de viktigste navigasjonshjelpemidlene en moderne web har.
• Hvordan er systemet dokumentert? Hvis man baserer seg på et Open Source-system, er vanligvis ikke dette det venskeligste kravet, all kode er tilgjengelig. Men hvis man kjøper et ferdig system, muligens et som driftes på leverandørens servere, er det viktig at man har god dokumentasjon og mulighet til å oppbevare sikkerhetskopier av informasjonen selv. God dokumentasjon og egne kopier gjør at man har mulighet til å migrere til et annet system dersom det eksisterende av en eller annen grunn ikke lenger er å anse som funksjonellt.
• Hvordan skal informasjonen produseres? Brukergrensesnitt som ikke fungerer, gjør at folk ikke vil produsere informasjon til systemet. Å få puttet informasjon inn, er selvfølgelig noe av det mest vesentlige ved hele publiseringssystemet. Å ta høyde for at man i fremtiden vil kunne ønske å gjøre ting på en annen måte enn i dag, er lurt også her. Dokumentasjon er med andre ord et stikkord også her.
• Hva er inkludert i driftsavtalen? Dette er egentlig et veldig selvfølgelig spørsmål, men jeg har flere ganger opplevd at en kunde forventer å få noe som leverandøren krever ekstra betalt for. Hvis kontrakten er uklar, går det gjerne slik som leverandøren ønsker.

Disse punktene er ikke bare viktige når man skal kjøpe en løsning fra andre, de er også viktige selv om organisasjonen selv har kompetanse til selv å utvikle, eller å ta i bruk et eksisterende, system. Folk flytter på seg og behov endrer seg, så dokumentasjon er minst like viktig. I tillegg må organisasjonen føle eierskap til systemet, noe prosessen med å komme fram til klare og entydige krav er den beste garantien for.