Internetdagarna och twitterväggen

I veckan som gick var det dags för Internetdagarna igen. Förra året hade jag det tveksamma nöjet att vara den som ansvarade för videosändningarna över webben och det gick åt helvete med det. Därför var det med yttersta glädje och tacksamhet jag överlät åt den alltid eminente och trevlige Björn Falkevik / SocialVideo att göra det i år. Och självklart gick det mycket bättre.

Men det fanns ju annat att göra på Internetdagarna. Förutom att hålla koll på webbarna, moderera ett seminarium om webbutveckling och vara allmänt trevlig och hjälpsam mot talare, besökare och medarbetare försökte jag ha lite koll på twitterflödet. Och ibland hettade det till lite, när några undrade varför vi inte visar twitterflödet på stora skärmar inne i konferenssalarna.

Flashback till 2009 när vi hade exakt samma diskussion, och jag försökte svara på exakt samma vis. Att vi faktiskt tänkt över saken men bestämt oss för att det får räcka med att visa flödet i hallen utanför konferensrummen, och att skälen är flera. Jag ska försöka sammanfatta dem här.

Skitsnacket bakom ryggen

Den som talar inför publik är troligen rätt nervös inför sitt framträdande. Jag vet att jag blir det, nästan oavsett storlek eller typ av publik. Och det står självklart fritt för var och en att kommentera framträdandet i valfri kanal. Twitter är en, och jag deltar gärna i den konversationen. Men för mig är Twitter under konferenser främst en “back channel”, dvs en inofficiell kanal där de invigda för en diskussion vid sidan om den officiella. Det är ju öppet för vem som helst att delta, särskilt när en konferens (som Internetdagarna) har en officiell hashtagg.

Men det betyder inte att man automatiskt ska “tvinga in” alla konferensdeltagare i diskussionen. En majoritet av konferensdeltagarna på Internetdagarna är inte Twittrare, eller väljer åtminstone att inte delta i diskussionerna på Twitter under konferensen. Och flera av dem tycker till och med att det är störande att ha flödet uppe på skärm samtidigt som en talare pratar, vilket vi fick höra förra året efter konferensen då en del av talarna på eget initiativ la upp flödet på projektorn under sina seminarier.

Det blir ofta en väldigt hård och kritisk ton på Twitter under en talares framförande. Nästan oavsett en talares kvalitet kommer delar av presentationen att sågas – om det inte är innehållet i talet så är det talarens röst, kläder, ålder eller utseende som behandlas. Och det är naturligt, eftersom Twitter har tonen av ett fikarum, skitsnacket som man håller över en kopp kaffe i korridoren. Men att ha det samtalet offentligt, och dessutom i ett format där alla i salen kan se vad som sägs om en talare samtidigt som denne inte har en chans att hänga med i samtalet, känns bara orättvist och rent av lite elakt.

Nu finns det ju de som menar att ett publikt och publicerat twitterflöde har motsatt effekt. Och det kan säkert stämma. Men jag har ännu inte sett några bevis på det.

Så – nu väntar jag på att få se lite goda exempel på konferenser där man visar twitterflödet bakom talarens rygg och där det inte sägs något negativt om talaren under tiden. Har du något sånt att visa mig?

/M;

Kommentarshatet kräver modiga beslut

DN.se har börjat välja bort läsarkommentarer på vissa artiklar för att minska problemet med “ett tilltagande problem med rasistiska kommentarer”. Sydsvenskan.se har på sin nya sajt installerat Disqus och kräver någon form av inloggning för direktpublicering. Vill du kommentera anonymt får du vänta på att bli förhandsgranskad av en moderator innan din text visas på sajten.

Bra! Det här är helt i linje med vad jag tidigare föreslagit här på bloggen och på internetdagarna.se. Stora varumärken som står för publicistiska värden har inte råd att låta sina webbtjänster tas över av anonymt näthat. Och självklart minskar hatet, struntpratet och trollandet när man tvingas skriva under sina texter med namn eller åtminstone en registrerad signatur.

Men det finns en sak kvar att prata om. DN gör ett misstag när de fortsätter med helt öppna kommentarer men väljer att stänga av kommentarer helt och hållet på bara vissa artiklar, och då främst på artiklar relaterade till invandringsfrågor. Det stämmer helt säkert som man säger att det är just de artiklarna som lockar fram de värsta trollen på nätet, men det var också precis samma attityd som gjorde Ny Demokrati till ett riksdagsparti och jag är rädd att det spelar Sverigedemokraterna rakt i händerna.

Fri debatt eller inte fri debatt – det är bara att välja

Att inte tillåta kommentarer på artiklar som berör invandring kan väldigt enkelt tolkas som ett försök att tysta en stark opinion, som att “etablissemanget” inte vågar lyssna på argumenten, att rasisterna inte får höras, helt enkelt. Det här är både farligt och antidemokratiskt! Antingen har vi fri debatt eller så har vi det inte – det finns inget mellanting.

Rimligen tillåter man alla inlägg som följer svensk lag och/eller egna regler för debatt som man sätter upp. Om det är för svårt att hålla ordning på kommentarsfloden när man har debatten öppen för alla, utan inloggning eller krav, så sätter man helt enkelt upp nya krav. Det går utmärkt att använda en hel bukett av inloggningslösningar samtidigt, och troligen blir man av med i runda slängar 99% av kommentarshatet när man kräver namn och inloggning, så vad väntar DN på?

Jag vill ge en extra stor nätkram till Sydsvenskan som tagit det modiga beslutet att rensa upp i kommentarsträsket! Det har naturligtvis straffat sig. Jag är ingen daglig besökare på sydsvenskan.se så jag vet inte hur många kommentarer artiklarna där hade innan “stoppet”, men idag är det ju väldigt få kommentarer på artiklarna där jämfört med alla andra stora svenska dagstidningars sajter. Det gör säkert ont, och kanske ser man också minskade klick när det blir mindre trollande i kommentarerna,  men jag är helt säker på att det var rätt beslut. Det var publicistiskt korrekt,nätmässigt modigt och ett ansvarstagande som kommer att bli vägvisande framöver. Många kommer att följa efter och vi kommer att få en bättre, hederligare och ärligare debatt på nätet som lön för mödan.

/M;

Nytt år, nya projekt

?ret är 2010 och jag har precis officellt påbörjat min anställning som webbansvarig på .SE. Det kommer inte direkt att bli tid över att fundera så mycket innan det börjar hagla projekt som ska genomföras.

Ett av de större projekten kommer att bli konstruktionen av en helt ny webbplats för iis.se som ska bli klar innan sommaren. iis.se är en webbplats som till största delen är en funktionswebbplats. En klar majoritet av våra besökare på sajten kommer dit för att göra slagningar efter lediga .se-domäner eller för att se vem som är innehavare av en viss .se-domän. Därför är det självklart att vi ska göra det så enkelt som möjligt att använda de funktionerna på den nya sajten, även om vi kommer att fortsätta vara tvungna att använda oss av en CAPTCHA ?? mer om det vid ett annat tillfälle.

En annan utmaning blir att förtydliga och förenkla informationen när det gäller domäninnehavarnas tillgång till kundtjänst. Efter övergången till registry-registrar-modell har .SE inte längre någon kundtjänst för alla de domäninnehavare som har sin domän hos en annan registrar än .SE Direkt. Det här är inte direkt solklart och i många fall även direkt förvirrande, så vi måste försöka hitta en mer pedagogisk lösning på hur vi förklarar vem man som innehavare ska vända sig till med kundtjänstfrågor. Ett första embryo till det ser vi på dagens iis.se där tjänsten “Vilken registrar tillhör jag” har tillkommit. Funktionsmässigt är vi nog framme där, men innehålls- och framförallt instruktionsmässigt har vi mycket kvar att göra.

Vi har även ett stort arbete framför oss när det gäller att tillgängliggöra alla våra guider på webben. Det känns sorgligt att alla dessa riktigt bra publikationer endast finns tillgängliga som nedladdningsbara PDF:er och här kommer vi att lägga en del krut på att göra en riktigt bra sajt av guideinnehållet.

Självklart kommer även nästa version av iis.se kommer att bygga på WordPress. Mer om mina tankar kring WordPress och vart webben är på väg kommer senare. Men en sak kan jag säga redan nu: Hade jag inte tagit anställning på .SE hade jag garanterat satsat på att bygga upp en renodlad WordPressbyrå.

/M;

Det är dags att kräva mer – eller åtminstone att börja filtrera

På de flesta stora papperstidningars webbplatser kan man kommentera artiklarna, något som länge var möjligt endast på bloggar, online-fanzine, webbtidningar och andra “onlinemedia” men som under 2000-talets senare hälft slog igenom med full kraft även på gammelmedias sajter. Först tyckte jag att tidningarna var sega med att införa kommentarsmöjligheter, men när det nu går att läsa folks kommentarer på snart sagt alla sajter där nyheter och aktuella händelser presenteras har jag ändrat mig. Jag vill inte vara med längre.

dn.se går det att kommentera nästan alla artiklar anonymt. Det enda du behöver fylla i är “Namn”, men självklart inte ditt riktiga namn. Möjligheten att vara anonym på nätet har jag alltid värnat om och tycker fortfarande att den är viktig ?? men när jag ser vad som händer med kommentarstrådar på dn.se eller aftonbladet.se blir jag mer och mer övertygad om att det är dags för tidningarna att antingen stänga av kommentarsmöjligheten helt och hållet eller också införa en inloggning kopplad till ett viktigare konto. DN är på god väg när man låter folk logga in med sitt Facebook-konto för att identifiera sig. Om de gjorde det till ett krav kanske nivån skulle höjas på diskussionen.

För sanningen är ju tyvärr att när folk samlas på nätet, särskilt runt en artikel eller text med brännhett stoff, blir folksamlingen snabbt en pöbel. Smårasistiska tillmälen blandas med “statistik” tagen ur luften, alla kallas för idioter kors och tvärs och väldigt, väldigt lite av värde går att läsa i en kommentarstråd på dessa sajter. Tyvärr. För egentligen är det just möjligheten till det offentliga samtalet som är intressant med bloggar, mikrobloggar och alla typer av onlinepublicering.

Kanske är det så att vi måste ge avkall på möjligheten till anonymitet på de ställen där den här typen av avarter uppstår. På internetdagarna.se har vi alltid haft öppet för anonyma kommentarer, som standard är på en WordPress-sajt, och jag tror att det bara är en enda gång som vi inte godkänt en kommentar. Uppenbarligen beror nivån väldigt mycket på vilken sajt som kommenteras, men frågan jag ställer mig varje gång jag mot bättre vetande lockas in i en kommentarstråd på en större svensk sajt är om man verkligen vill ha den typen av innehåll på sin sajt, under sin logotyp. Innehållet på Aftonbladet är ju kanske inte det bästa till att börja med, men när innehållet sänks ytterligare av den otroligt låga kommentarsnivån är det läge att tänka om, tycker jag.

Slashdot har löst det här på ett rätt elegant sätt, tycker jag. Genom ett betygssystem i skalan 0-5 för kommentarer, där anonyma kommentarer automatiskt får en lägre poäng från början än inloggade medlemmars kommentarer, och möjligheten för alla medlemmar att betygsätta andra kommentarer har man byggt en hierarki som funkar rätt bra. Som besökare kan du själv välja vilken lägsta nivå du vill läsa kommentarer från, och kan därmed sätta ribban högt eller lågt. Väljer du att läsa alla kommentarer som postats får du mycket trams, men missar inget. Väljer du istället att bara läsa kommentarer som fått betyg upp till tre eller högre är det generellt mycket bättre nivå på innehållet.

Om jag vore ett stort mediebolag med en stor sajt med mycket innehåll skulle jag genast utvärdera anonyma kommentarer och fundera på ett rankingsystem liknande Slashdots. Inte bara för att man upplåter plats till pöbeln, utan främst för att man bör värna om sitt varumärke. Det fria ordet är viktigt, självklart. Men vi har nått en gräns där det inte längre är rimligt att man får vara anonym alltid, hela tiden.

(Det här är ingen ny fråga, fler har skrivit om problematiken.)

/M;

Hur man kommunicerar som kommunikationsbyrå

Jag har plötsligt hamnat i en situation på mitt jobb där jag behöver sondera terrängen efter produktions- och/eller kommunikationsbyråer. Eftersom det var ungefär tio år sedan jag gick från att vara köpare till att vara säljare av kommunikationstjänster så var det med nya ögon jag gjorde en klassisk Googlesökning efter “kommunikationsbyrå Stockholm“.

Vad händer när man gör en så bred Googling? Jo, först av allt ser man självfallet de som köpt annonsplats hos Google för att visas vid min sökning. Här låg tre byråer med olika hög profil men alla med relativt slagkraftiga budskap på sin begränsade yta:

Googleannonser på "Kommunikationsbyrå Stockholm"

?verst låg “?kesson & Curry” så de fick mitt första klick. Jag är ju trots allt en dum köpare som just har gjort världens bredaste sökning. Troligen vill jag ha dem som ligger högst upp! Inne hos “akessoncurry.com” (.com-domän! Redan här började det osa katt) blev jag välkomnad med ett Flashbildspel som visade att byrån blivit “nominerade i tre kategorier” till Guldbladet 2009. Det lät spännande så jag tryckte på bilden, som hade en trasig länk så jag fick ett felmeddelande slängt i ansiktet. Olycksfall i arbetet? Kanske, men här har man redan uppnått tre fatala misstag för mitt köp (.com-domän, Flash och trasig länk ?? men det är ju tre önskningar i en, det går ju inte!) så jag gick vidare till tvåan.

Grand River öppnar rätt starkt med en ren webbdesign och tydligt (om än lite väl fluffigt) budskap om att 1+1 kan bli 3, så jag blir nyfiken nog att klicka vidare. Under “Tjänster” listar man det som byrån kan hjälpa mig med. Här finns såväl marknadsundersökningar och kommunikationslösningar som grafisk produktion, men inget av valen ger konkreta exempel på vad man erbjuder, utan endast mera copytext om att “Vi försöker uppnå en känsla hos mottagaren att just den här organisationen vill kommunicera med ‘mig'”. Men så bra då. När jag sen klickar på “Kunder” för att se några case får jag bara mer flufftext och fortfarande inget som helst konkret förevisat. Inga bilder, inget som visar vad man faktiskt producerat. Det här är totalt #fail för mig som köpare. Jag vill se mer innan jag tar kontakt.

Vidare så till trean i listan – Frosting. Nu börjar det faktiskt likna nåt! Frosting har en snygg sajt, dock i AIK-färger (men jag förlåter dem för den här gången) och balanserar på precis rätt sida om vad som är vettigt i användande av Flash och textbilder. Under “Om oss” berättar man faktiskt rätt utförligt och konkret om företaget med sina medarbetare och sitt arbetssätt. Det här känns inbjudande och relevant för mig som köpare. När jag sen går vidare till “Portfolio” har man en stor mängd case med bild och beskrivning, och det går faktiskt att läsa rätt mycket om varje case. Dessutom går det att sortera på vilken typ av uppdrag man haft (webb, print, event, etc) och beskrivningstexterna är precis lagom långa för att man ska kunna få insyn i vad man gjort. Den enda kritiken jag har här är att det är lite otydligt vad som är länkar och inte, eftersom både länkar och underrubriker är gula, utan understrykning, men det är ju en petitess i sammanhanget.

Tre byråer, tre olika sätt att presentera sin verksamhet. Endast Frosting lyckades övertyga överhuvudtaget.

Nu kanske ni tycker att jag är dum som bara trycker på sponsrade länkar. Men nejdå, jag tittade faktiskt på första sidan av sökresultat också. Här dominerar Tullbergs, som uppenbarligen lyckats med sin SEO. Man är den ENDA kommunikationsbyrån som finns med på första sidan alls! Alla andra länkar är till kataloger, aggregerare och diverse mer eller mindre spammigt automatgenererat innehåll. Det här borde vara en väckarklocka för de företag som tycker att de ska hålla på med kommunikation. Jag säger inte att alla kan synas på förstasidan hos Google, självklart funkar det inte så, men när ett företag dominerar så fullständigt som Tullbergs gör här måste de få rysligt många besökare från Google beroende på hur vanlig min sökning nu är.

Det verkar som att det kommer att bli svårt för oss att hitta en byrå, och det verkar som att det är svårt för byråer att kommunicera på webben. Om man alls vill sälja webb borde man vara mycket bättre på att producera sin egen webb. Jag vet av egen erfarenhet att det lätt blir så att den egna sajten hamnar längst ner på prioritetslistan, men efter att ha ställt mig “på andra sidan” inser jag ändå mer än någonsin förr hur viktigt det är att ha en bra och tydlig sajt för sitt företag.

/M;

Mina erfarenheter från streaming av Internetdagarna

Skärmavbild 2009-11-19 kl. 19 nov, kl 14.41.07, v 47

Under Internetdagarna 09 hade jag tagit på mig att genomföra ett antal livesändningar från seminarier och keynotes. Eftersom det inte hade gjorts någon gång under tidigare Internetdagarna var det här ett experiment både för .SE och för mig. Vi valde att göra det själva, och i liten skala, eftersom vi inte hade någon uttalad budget och inte heller var säkra på intresset för sändningarna.

Under sensommaren och hösten testade jag olika typer av utrustning för eventet. Vi köpte in en kamera, en Canon Legria HV40 och testade ett antal olika tjänster och mjukvaror för själva streamingen. Valet föll på Livestream, en amerikansk tjänst som används av många stora sajter. Anledningen till att vi valde Livestream var främst att vi med ett premiumkonto hade möjlighet att skapa en egen Flashspelare, som vi kunde anpassa så att den passade in på förstasidan på internetdagarna.se.

Livestreams premiumkonto kostar 350 USD i månaden, och dessutom betalar man för den bandbredd och lagring man faktiskt använder. Jag gjorde lite överslagsräkningar och fick fram att det inte skulle bli så dyrt, vilket visade sig vara fel. Mer om det senare.

Möjligheten att kunna designa sin egen Flashspelare var som sagt det stora skälet till att vi valde Livestream, men även kvaliteten på strömmen vid våra tester övertygade. Jag använde både Livestreams Flashbaserade webbklient för att strömma, såväl som deras Windowsprogram, Procaster. Vid mina tester tyckte jag att Procaster gav bättre kvalitet vid låga bitrates, och jag hade dessutom möjlighet att skräddarsy bitrate på video och ljud, och det fanns flera andra inställningsmöjligheter. Jag beslutade därför att vi skulle använda Procaster vid livesändingarna.

Livestream har en “ren” Flashspelare för nedladdning som jag kunde använda för att skapa vår egen spelare. Det var väldigt lätt att anpassa spelaren efter våra behov, och vid mina tester såg allt bra ut. En vecka innan Internetdagarna besökte jag Stockholm City Conference Center för att testa på plats, och såg att ljusförhållandena var väldigt dåliga, men det var för sent att göra något åt det. Vi hade redan beställt ljudkablar, nätverkskablar och strömkablar fram till de platser jag skulle befinna mig vid sändningarna.

Den 3 november var det så dags. Jag åkte till eventet tidigt på morgonen för att reka och ställa i ordning. Ljud och nätverk fanns framdraget, men jag upptäckte då att nätverket jag fick ansluta till var skyddat av en brandvägg, vilket krävde att jag gjorde en sessionsinloggning på datorn. Sagt och gjort, jag loggade in och nätverket flöt på bra. Ljudet fick jag tappat från mixerbordet i en kabel som jag sedan anslöt till den lilla mixer jag själv använde för att reglera volymen in i datorn. Inför första sändningen la ljudteknikern ut musik i kabeln och jag testade nivåer så att allt lät bra.

När det var dags för att börja första sändningen var det mesta på banan – sajten låg uppe, strömmen såg bra ut, men jag upptäckte genast att ljudet från mikrofonerna som kom i min kabel var kraftigt distat. Där jag satt mitt i hörsalen kunde jag inte springa bort till ljudteknikern och försöka göra något åt det, så ljudet fick helt enkelt vara distat. Det här problemet gick att åtgärda till följande seminarier, så det var bara den första sändningen som hade riktigt dåligt ljud, även om flera andra sändningar också hade långt ifrån perfekt ljud senare.

Efter några minuter började så problemen. Jag kunde hela tiden följa utvecklingen i Procaster, som visade exakt hur många rutor per sekund (fps) som programmet skickade ut på nätet. Vid seminariets början låg vi på runt 20 fps, vilket är mer än godkänt. Men efter några minuter började siffran att dala. 15 fps, 10 fps, snart var vi nere i 3 fps och sändningen såg ut som någon slags hackigt bildspel snarare än film… Jag försökte febrilt hitta källan till problemen, och upptäckte att jag inte hade någon som helst kontakt med Internet från något annat program på datorn. Det gick inte att surfa, det gick inte att pinga. Jag insåg att min nätuppkoppling hade strypts av någon anledning. Till slut dog strömmen helt och hållet, och jag blev tvungen att starta om datorn för att få komma ut på nätet igen. Mitt i alla dessa problem började dessutom mjukvaran för sändning, Procaster, att strula, och jag fick starta om programmet nån gång efter att det kraschat. Det här hände aldrig under mina tester, så jag misstänkte att de hade något att göra med problemen med Internetaccessen.

Efter detta första seminarium tackade jag mig själv för att jag varit förutseende nog att lägga in en ordentlig paus mellan första sändningen och andra. Jag hade nu ett par timmar på mig att försöka reda ut vad som gått fel och åtgärda det. Jag ropade ut min förtvivlan på Twitter och fick omgående ett erbjudande om hjälp från Björn Falkevik, stjärnan på webbsändingar. Björn ringde mig direkt (vilken hedersman, denne Björn!) och försökte på alla sätt hjälpa till att ta reda på exakt vad som gått fel. Björn hade själv sänt från samma konferenshall tidigare och visste bland annat att det gällde att se till att få Internetaccess utanför brandväggen.

Jag insåg genast att jag måste göra något åt nätverket, och bad därför Stockholm CCC om att kablarna jag fått framdragna till respektive rum nu skulle ge mig access till Internet utanför brandväggen. Det skulle man ordna, även om det kunde bli lite ont om tid på sina ställen. Jag bestämde också genast att jag inte längre vågade lita på Livestream eller Procaster, och bestämde därför att jag skulle prova med Bambuser, fast jag då skulle vara tvungen att slänga bort min egen Flashspelare och istället bädda in Bambusers spelare på internetdagarna.se.

Resten av Internetdagarna sände jag alltså med Bambuser, och det var en enorm skillnad. Den Flashklient som Bambuser har för att sända direkt från sin dator funkade klockrent, helt strulfritt och extremt smidigt. Kvaliteten var något sämre än med Livestream, men eftersom ljuset och andra förutsättningar var så dåliga på plats var det knappast något som påverkade slutresultatet nämnvärt. Ljudet funkade bra i de flesta fall, även om det fortfarande var problem med distorsion i vissa rum.

Eftersom jag ändrat min beställning gällande Internetaccess på plats fick jag även fortsättningsvis problem med nätet till och från. I de fall jag hade fungerande Internetlina gick webbsändningarna helt utan problem. Någon gång funkade helt enkelt inte kabeln alls, och då fick jag sända på konferensens WiFi-nät, vilket gick bra en av gångerna och sämre en annan.

Vilka slutsatser och lärdomar drar jag då av allt det som hände? Först och främst måste jag ge ordentligt med beröm till Bambuser. Här har vi en tjänst som bara fungerar. Nästa gång jag ska strömma video (vilket jag ska göra den 10:e december från “Misstag och floppar” så tänker jag fortsätta använda Bambuser, även om jag tittar på att använda Wirecast eller någon annan mjukvara för att få bättre kontroll över innehållet. Det är lite synd att jag inte kan göra en egen Flashspelare till sajten, men jag kan leva med det om det bara funkar som det ska.

En annan sak som är trevligt med Bambuser är att tjänsten är gratis. Livestream har också en gratistjänst, men den premiumtjänst vi köpte för att kunna göra vår egen spelare kostar som sagt 350 dollar i månaden. Sen tar man också betalt för bandbredden som används, och här hade jag räknat ordentligt fel. Efter den enda utsändning vi gjorde med Livestream så såg jag att vi dragit på oss ungefär 150 dollar i bandbreddskostnader! Detta på runt 70-80 tittare under nån timmes tid. Hade vi fortsatt att använda Livestream under hela Internetdagarna hade det hela blivit en mycket dyrare affär.

Permanenta länkar – vad är det?

I en debatt på mindpark.se stångades jag en stund med Joakim Jardenberg om vikten av absolut permanenta länkar på webben. Jag uttryckte min oro för att Jardenberg är på marsch mot ett förstelnande Internet och att göra ett stilleben av webben, eftersom han förespråkar att en länk är en länk är en länk, och absolut aldrig får brytas.

Jag förstår mycket väl vad han menar, det är tråkigt att bryta inlänkar och indexering i Google och andra sökmotorer, men jag är av uppfattningen att webben likt Internet i stort är under ständig förändring, och att vi inte kan bli för nostalgiska vad gäller en teknik eller något innehåll på webben. Och självklart förstår jag det positiva i att länkar inte bryts, men jag tycker helt enkelt att det finns många tillfällen då nackdelarna väger tyngre än fördelarna.

Nå – Jocke gick till så hårt angrepp att jag la några minuter på att slå hål på hans teorier genom att hitta trasiga länkar på en sajt han själv ansvarat för: hd.se. Lättare sagt än gjort skulle det visa sig, för man har verkligen ansträngt sig till det yttersta för att bevara gamla länkar.

Jag hittade till exempel följande länk genom att söka på Google: En artikel från Elöverkänsligas Riksförbund från 2004. Här länkas en artikel på hd.se som handlar om att Båstad sagt nej till nya 3G-master. Länken är som följer: http://hd.se/ArticlePages/200409/28/20040928161250_-Alla_anvandare-191/20040928161250_-Alla_anvandare-191.dbp.shtml

Ouch. Inte världens snyggaste URL direkt, men så ser den ut. Jag tänkte att jag hade hittat guldkornet jag letade efter, men blev snopen när länken faktiskt fungerade, och dessutom ledde rätt: http://hd.se/bastad/2004/09/28/baastad_saeger_nej_till_nya_3g/

Här har man ju uppenbarligen lyckats med att behålla en gammal inlänk så att den funkar, och leder till den nya länken. Imponerande! Finemang! Alla är glada. Eller? Jag kan inte låta bli att fundera lite på hur man gått tillväga. Den gamla URL:en innehåller datum för artikeln (20040928) och vad som gissningsvis är ett internt ID för artikeln från det CMS man använde 2004 (161250). Den nya URL:en innehåller inget ID alls, utan använder en modern permalinkstruktur där titeln från artikeln blir identifikationen (baastad_saeger_nej_till_nya_3g), så hur görs kopplingen från den gamla URL:en till den nya?

Här får jag gissa. HD kanske använder samma CMS nu som 2004, och i såna fall har artikelns ID troligen inte ändrats sen dess, och det är lätt att göra ett nytt fält i datbasen för “snyggare URL:er”. Men desto troligare är att HD har bytt CMS sedan 2004, och då kan man ha gjort på två olika sätt:

1) Man kan ha behållit alla ID-nummer från det gamla CMS-systemet när man importerade innehållet till det nya.

Det är ofta komplicerat, och en vanligare lösning är att man istället

2) häller in gamla ID i ett separat fält för detta (oldID, anyone?) för att bibehålla kopplingen.

Har man valt lösning (1) är det hatten av och bara att köra på. Det är väldigt lätt att göra en “rewrite” på gamla URL:er till nya i det fallet. Har man istället använd lösning (2) börjar jag få rätt i min argumentation på mindpark.se. För hur många generationer av gamla system ska man egentligen underhålla innan det blir löjligt? Visst, en generation kan man utan större problem underhålla för att ha permanenta länkar, men nästa gång man byter CMS, blir det ytterligare en generation av ID att hålla ordning på då? Och nästa gång, och nästa gång…

Min princip ligger fast – det ?R inte alltid försvarbart att till varje pris behålla länkstrukturer när man gör ett större systembyte. Det är lovvärt om det går att göra, och det finns ju inga nackdelar med att göra det om det är enkelt. Men om det är svårt, om det kräver att man hackar speciallösningar, och om det på sikt ändå är ohållbart – var går gränsen?

Och det som jag ser som det större problemet i den här frågan – ska vi verkligen betrakta webben som permanent? Kan vi inte acceptera att länkar bryts då och då? Finns det inte en ganska stor risk att vi på sikt hamnar i en okontrollerbar härva av föråldrade länkar som ska underhållas i all evighet?

/M;

DN.se:s iPhone-version bra, men inte perfekt

DN berättar stolt om sin nya iPhone-anpassade version av mobilsajten på mobil.dn.se idag. Själv upptäckte jag den för nån dag sen, när jag som vanligt surfade in på mobil.dn.se från min iPhone – den befintliga versionen av iPhone, som inte har 3G-hastigheter.

Den nya iPhone-versionen är snygg, mycket snygg. Den använder sig av standardiserade ikoner, knappar och annat som gör att det verkligen känns som en fullfjädrad iPhone-webbapp. Men tyvärr är den så seg, så seg att den i princip är oanvändbar på min iPhone när jag inte har tillgång till wifi.

Jag förstår att DN anpassat sin iPhone-sajt till iPhone 3G som är den första versionen av telefonen som släpps officiellt i Sverige om några dagar, men med tanke på hur många det är som “grå-importerat” en iPhone från USA och använder dem här i Sverige tycker jag att DN borde ha haft detta i åtanke innan de bestämde sig för att skicka vidare alla iPhone-browsers helt osorterat när man surfar in på mobil.dn.se.

DN:s mobilsajt brukade vara den allra bästa för mig, men nu är den oanvändbar. DN borde låta mig som iPhoneanvändare välja om jag vill fortsätta använda den nya, iPhone-anpassade versionen eller om jag vill komma till “vanliga” mobilsajten när jag surfar in.

Snälla DN, gör så jag kan komma tillbaka till den gamla mobilsajten!

/M;

Efficient dual caching of dynamic web content

Last Tuesday, I held a short presentation at the very first “Web Monday” held in Stockholm (don’t ask why it was on a Tuesday) about a technique I used at the site I run, arkadtorget.se. The cache method I implemented there was the result of a series of discussions I had with my very good friend Peter Svensson, who is the smartest scatterbrain in the county, if not the country, or the world.

Peter, who has recently become a Javascript wizard and evangelist, suggested that I solve a problem I had with heavy load on the MySQL server at Arkadtorget by implementing a client-side cache. Storing content in local Javascript variables in the web browser. I had already determined that I needed to build and implement a server-side cache using PHP to write the results of MySQL queries into text files that I could later read from instead of bugging MySQL about the data again just because another user wants to read the same forum thread that another one just did.

There are plenty of PHP caching solutions out there, most of them using a similar method of writing database results into text files. To use server-side caching is a very wise and good idea in general, for almost any web site with common database access. Usually, the method is used to cache complete web pages after they have been rendered by a CMS or other web system. The complete resulting HTML from a complex series of PHP-parsing and database queries is stored in a text file on the server before being sent to the web browser. The next time a client requests the very same page (usually determined by the URL/query string used to access the content) the server can return the contents of the text file instead of again parsing PHP and making several database queries.

I use my cache methods mostly to cache parts of pages that I know are difficult for PHP/MySQL to render. This is often lists, tables of different kinds and simple counters or searches that are repeated a lot, but where the data does not neccessarily need to be 100% fresh. (What if it does need to be 100% pristine, fresh and healthy-smelling? More about that later.) In fact, sometimes I use server-side cache to store many parts of a page, separately and modularized, so that the same module (say, a sidebar navigation or statistics used in many different places on a site) can be called upon an unlimited amount of times without asking the database to check its rows more than once ?? i.e. the first time the content is rendered, and subsequently cached.

Now, since we are talking about tables and lists, I have made an observation regarding user behaviour and pagination. After logging every click a user makes on a paginated list of results, I noticed that the very pagination itself seems to encourage “flipping” back and forth between pages of results. I even started noticing myself doing it. I’d make a web search on Google, scan page one of results, click to page two, maybe to page three and then think “what was that third link on page one?” and flipping back to page one, checking it before flipping back to page three again and then on to four, and so on.

What’s going on here? In my logs, I could see that as many as 33% of the requested pages were pages I had already sent to the browser, during the same session! (Note, this is at a local, Swedish-language forum full of tech/arcade nerds – YMMV) Even if I have used on of the common cache methods in PHP to store the forum pages in a text file on the server, the client will ask the server for updates on every page, and with even low latency and a properly working cache, there will be plenty of requests sent from the client to the web server for changed graphics, included files, etc. (Most of which are preventable if you have set your expires headers correctly! More on this in another post.)

Now, I was already planning to migrate the forum to an AJAX-powered fetching method, but even using AJAX to get the contents of the forum, I would have to ask the backend for the same code, over and over in up to 33% of the time! This is where my friend Peter had the idea to circumvent the extra round trips to the web server by storing the HTML needed to print the pages in a local JS variable.

Simple, elegant, yet powerful. Every time a user requests a page he has not previously viewed I ask the AJAX backend (built with PHP) for the HTML-code needed to print the page. The PHP code will use the server-side cache method to make sure that the database will not have to bother with presenting content for the page, if it has been loaded before, and send the HTML-code ?? from text file cache or not ?? to the client. The browser, upon receiving this content for the first time, displays it for the user to read, but also quietly stores the entire page of data in a Javascript variable. If the user ends up going to page two and then wants page one again (“flipping” as it were) we can check to see if page one is already present in the local cache, and serve up the content of the Javascript variable straight, on the rocks, without even checking with the server to see what time of day it is! It’s a beautful solution, especially since the users who are doing the “flipping” notice nothing, except that a page they already visited before is loading instantly, without any noticable delay.
In fact, why stop there? I made some changes to make sure that the user experience is even more smooth by telling my AJAX backend to let the browser know whether the next page in the result set is available as server-cached content (I don’t want to bother the database if I don’t have to ?? I don’t know that the user is actually going to ask for the next page) and if it is, the browser will then proceed to load the next page of results straight into the local Javascript variable. The user sees and notices nothing of this, except if he clicks the next page, in which case I can now present that content instantaneously, without asking the server “hey, hand me page two ?? stat!”.

OK, so what was actually gained here? First of all, the user experience is greatly improved. The dual caching method makes this forum seem fast as lightning, most of the time. Secondly, the database can take a deep breath of relief, since I never have to ask it for content it’s already served up once.

Which brings us to the server-side cache, and its expiration methods. A common practice is to define a timeout, an interval of time during which the content will be considered fresh. When the predefined time is out, the content will be generated by asking the database the very next time it is requested by the user. This works great for content that doesn’t need to be 100% fresh, all the time. With a relatively conservative timeout, say 15 minutes, any content on the site is never more than 15 minutes old, even if it’s being read from the server cached text files. But what if 15 minutes is too long? In my case, I have a fairly active forum that needs caching, and 15 minutes is a very long time to wait between posting a message and actually showing it on the site.

We could, of course, delete the entire stock of stored text files containing the cached data every time a user posts in the forum. This would make sure that no cached content will be presented in case there is new data in the database. However, I don’t think that this is a very good idea in my case, because I have literally thousands of cached snippets (think hundreds of forum threads times tens and sometimes hundreds of pages) and deleting all of them would actually take some time for the server. Also, I am throwing the baby out with the bath water by deleting a lot of data that is not expired by a user posting in that very forum thread.

The answer is again, simple. Always make sure that you can back-reference a cache file with its content! A very common method for storing cache files on the server is using a hash (usually md5()) to make a unique filename for the content being cached. However, the drawback is that once you’ve md5()-ed, you can’t go back, since you can’t make potatoes out of fries or a cow from a hamburger. In my case, I decided on making up the file names of the cache files based on the content being cached. If I am caching forum 34, thread 34124 and page 2, the cache file is called “34-34124-2.cache”. Simple, no?

“But”, you say. “Having thousands of small text files on the server will make the request slow anyway, since the time the server needs to look up a file grows with the number of files in the same folder!”

Yes, it does. Have you ever made the mistake of not deleting session files in Apache after the session is expired? After a while, the web site will be extremely slow when Apache tries to locate your session file in a folder with a million files. My solution was to make a folder structured based on the md5() of the cache name, but using only the first two characters from the md5(). So, I currently have 235 folders storing the cache data, but I retained back-referencing!

This solution is so simple it could be used anywhere paged results are used. It costs next to nothing to implement (a little memory usage on the client, but unless you have pages of HTML using hundreds of kilobytes, this is of no concern) and there is no drawback to the method. Faster browsing, less traffic and load on the server is your reward.

Here is a tiny bit of example Javascript just to show what I am talking about:

[quickcode:noclick]function printThread(forumid, threadid, page) {
// Check for local cache first – pagesCached is an array of booleans,
// pageCache is an array of strings containing local cached content.
if (pagesCached[page] && pageCache[page].length > 10) {
alert(“From JS cache”); // We have a local cache!
// First, choose what div to write to
div = document.getElementById(“forumthread”);
// Next, set the innerHTML of that div to the content of local cache
div.innerHTML = pageCache[page];
// Now, if the next page in the result set is not
// already present in the local cache – go get it!
if (!pagesCached[(page+1)]) {
// Insert your own loading/caching code here
}
}
else {
alert(“From AJAX”);
// Go get the page from the server,
// but don’t forget to cache it locally afterwards!
}
}
[/quickcode]

/M;