Publiseringsløsningen EPiServer er en av de publiseringsløsningene Tarantell har ekspertise på, og som vi tilbyr våre kunder. Som EPiServer-partner er viktig at Tarantells utviklere som jobber med EPiServer holder seg faglig oppdatert, slik at vi kan levere løsninger med den høye kvaliteten Tarantells kunder forventer.
Siste versjon av publiseringslønsingen heter EPiServer CMS 6, og ble lansert 23. mars iår.
Annethvert år arrangeres EPiServer Partner Summit, en konferanse EPiServer arrangerer for sine partnere. Konferansen fant i år sted i Malmø, hvor omtrent tre hundre EPiServer-entusiaster møttes til tre dagers fullpakket program. Fra Tarantell deltok Øystein Pedersen, Marius Slette Johansen, Anders Gotaas Nordby og Håkon Kvalen.
Konferansen startet med et inspirerende og tankevekkende foredrag av fremtidsanalytikeren Troed Troedson fra Paradigmmäklarna om samfunnsutviklingen – fra den industrielle revolusjon, via vår tid, og et stykke videre fremover. Spesielt tanken om hvordan informasjonsstrømmen øker, samtidig som strukturen minsker, og hvordan dette kan relateres til bruk av sosiale medier, var besnærende. For mange ble dette foredraget konferansens høydepunkt.
Et annet høydepunkt på konferansen, var da EPiServers Rikard Ljungman presenterte det splitter nye EPiServer Commerce – en fullverdig nettbutikk-løsning fra EPiServer. Den nye EPiServer Commerce-lønsingen var noen mange konferansedeltagere var spent på, og hovedinntrykket var at folk flest var imponert over det som ble presentert. Hittil har man ofte integrert andre nettbutikk-løsninger i EPiServer-prosjekter, men nå kan altså også EPiServers egen løsning vurderes.
Analytiker Peter Burris fra Forrester holdt en interessant keynote om at sosiale medier ikke bare er verdifulle i B2C, men faktisk vel så viktige i B2B.
Det var mange paralelle løp under konferansen, og nok av spennende foredrag å velge blant. Selv var jeg godt fornøyd med de programpostene jeg valgte; jeg lærte mye faglig nyttig som jeg kan ta med meg videre til de EPiServer-prosjektene jeg jobber på.
Fredag kveld dro vi ut til Luftkastellet ved Öresundsbroen, til middag og EPiServer Partner Awards. Tarantell gratulerer Making Waves med prisen for Partner of the Year i Norge.
I tillegg til faglig påfyll, ble det også tid til sosialt samvær med andre EPiServer-utviklere, og det ble knyttet nye kontakter med andre EPiServer-entusiaster, som kan nyttige i tiden fremover. Noen av disse “kjente” jeg fra før via blogger og lignende, men det er alltid hyggelig å møte folk ansikt-til-ansikt.
Konferansen ble avsluttet i København, med ølsmaking hos Carlsberg, guidet båttur og en tur på Tivoli.
Under hele konferansen har det vært stor aktivitet på #epips2010 på twitter. Konferansen hadde også sin egen konferansesite for mobil, hvor programoppdateringer og slikt var å finne.
Konferansen har gitt oss som jobber med EPiServer et godt innblikk i hvordan EPiServer selv tenker om sine produkter og strategier, og hvor mye EPiServer verdsetter sine partnere. Vi sitter igjen med et inntrykk av hva EPiServer har å tilby våre kunder, og hvordan vi kan levere bedre løsninger. Med en gjennomtenkt strategi som støtter dagens og morgendagens løsninger, er vi trygge på at EPiServer er produktet våre kunnder kommer til å glede av i mange år fremover innen Communication, Content, Commerce og Community.
For oss utviklere som er opptatt av å levere kvalitetsløsninger så har konfigurering av deploymentpakker for ulike miljøer som test, stage og prod vært problematisk og tungvint.
En nokså populær måte bygge deployment pakker på har vært å bruke Mavens funksjonalitet til å definere profiler og filtrer. På denne måten får man definert hvilke konfigurasjonsfiler som skal være med i de ulike miljøene. Ulemen med denne løsinger er at man ender opp med en pakke for hvert miljø, noe driftspersonal ikke ønsker. De ønsker å kunne deploye den samme pakken i alle miljøene.
For å løse dette så er det ofte vanlige å trekke ut konfigurasjonsfiler av deployment pakkene, og legge dem på et bestemt sted(/etc/konfig.properties) hvor de blir lest ved oppstart. Ulempene med denne løsningen er at konfigurasjonsfilene blir spredd ut over forkjellige maskiner. Dette gjør det tungvint å refakturere og endre på strukturene av konfigurasjonsfilene. (I stedet for å endre på konfigurasjonsparameter så beholder man det subboptimale for å unngå å måtte gjøre endringer på flere forskjellige maskiner.) En annen svakhet med denne løsningen er at det blir vanskelige å holde styr på hvilke parameter som er satt i de ulike miljøene for eksempel når man introduserer nye parameter.
En bedre løsning hadde vært å kunne gjøre alle konfigurasjonene på en plass i en fil. Dette er nøyaktig hva Constretto muligjør.
Constretto er et java open-source rammeverk laget av Kaare Nilsen fra Arktekk som gjør det mulig å deploye samme pakke i flere miljøer. Constretto kan ta konfigurasjonsfiler på to forskjellige måter.
Den første er en variant over java properties filer og ser slik ut:
parameter1 = min felles verdi
parameter2 = enda en felles verdi
@test.parameter3 = en verdi for test
@stage.parameter3 = en annen verdi for stage
@prod.parameter3 = en tredje verdi for prod
Vi har altså parametrer som er felles for alle miljøene, samt parametere for hvert miljø.
Den andre konfigurasjonsmåten er basert på gamle gode ini-fil-notasjonen:
[default]
parameter1 = min felles verdi
parameter2 = enda en felles verdi
[test]
parameter3 = en verdi for test
[stage]
parameter3 = en annen verdi for stage
[prod]
parameter3 = en tredje verdi for prod
Så dette var to forskjellige konfigurasjonsmåter, men hvordan vet hvert miljø hvilken parameter3 som skal brukes? Dette gjøres med å angå ved oppstart av java hvilket miljø man er i. For test vil det være –DCONSTRETTO_TAGS=test, og så vil Constretto lese de riktige parameterne.
Til slutt, hvordan kommer disse parameterne inn i selve java-applikasjonene? Bruker man Spring rammeverket så har Constretto en konfigurasjonslaster som oppfører seg veldig likt Springs egen property-placeholder, og som gjør at man når parameterne med vanlig ${parameter3} notasjon:
En annen måte å få injektet parameterverdier på er å bruke Constretto sine egne snertne java annotasjoner:
public class KonfigKlasse{
private String parameter3;
@Configure
public void configure(String parameter3){
this.parameter3 = parameter3;
}
Alt i alt så har dette revolusjonert konfigurasjonsstyring av java applikasjoner for meg. De er nå mye lettere å vedlikeholde og vi har nå en helt ny kontroll på hvilke parameter som blir brukt i de ulike miljøene.
Av variantene over så foretrekker jeg ini-filer sammen med java annotasjoner.
Tarantell hadde fire deltakere på årets Web 2.0 Expo i San Francisco. Konferansen arrangeres to ganger i året (vår/høst i henholdsvis San Francisco og New York) i regi av O’Reilly media. Tema og bakgrunn for konferansen er Tim O’Reilly’s fellesbetegnelse web 2.0, der hovedformålet var å skape en felles terminologi for alt som endrer vår oppfatning av hva internett er, kan brukes til og hvorledes det påvirker både vår forretningdrift og våre liv.
Konferansen er et viktig møtepunkt for alle som er opptatt av hva som venter rundt neste hjørne på internett – samt en realitetssjekk på hva som fungerer (eller ikke fungerer) med dagens plattformer, løsninger og forretningskonsepter.
Vi har tatt med oss noen hovedtrender fra Web 2.0 Expo. Hver av dem en verdt en eller flere blogginnlegg, og vi vil komme nærmere tilbake til de enkelte trendene.
Here goes:
Trend #1 : Lokalisering er overalt
Utnyttelse av sosiale medier med lokaliseringstjenester er på alles lepper. De fremste tjenestene pr. nå er businessorienterte Foursquare og tamagotchi/pokemon-inspirerte Gowalla. Google og Facebook er på vei med sine konkurrerende tjenester, så dette skal bli et uoversiktlig landskap å orientere seg i. Det som dog er viktig å ta med seg er:
Dialog mellom mennesker inneholder stedsinformasjon. Overhør en telefonsamtale på bussen og sjekk selv. Sosiale medier er fremfor alt om dialog, og disse mediene kommer følgelig til å oversvømmes av lokaliseringsinformasjon.
Virksomheter ønsker å vite både hvem kundene er – og hvor de er. At man også kan bruke sosiale medier til å trekke kunder inn i de fysiske butikkene er ett av Foursquares verdiforslag.
SFs svar på Ruter (BART) har brukt Foursquare for å øke antall reisende med offentlig kommunikasjon. I en kundeundersøkelse sier 19% av de spurte at de hadde reist med BART basert på en anbefaling fra en digital venn, og 38% syntes offentlig transport var “more fun” med mobile lokaliseringstjenester.
Lokaliseringstjenester kommer til å bli stort – og forhåpentligvis mer oversiktlig enn det er idag.
Trend #2 : HTML5 er den nye vinen
Hva skal man si? ALT kan gjøres i HTML5. Audio, video, skalerbar vektorgrafikk, 3D, SQL, webfonter etc. etc. Dette kan erstatte Flash, Silverlight og andre pluginbaserte utvidelser. De dårlige nyhetene er at implementeringen varierer kraftig fra nettleser til nettleser, og Microsoft er ikke på banen ennå. Vi står med andre ord foran flere år med browserkrig. Google har prøvd å imøtegå dette ved å lage en Chrome plugin til IE, noe som virker som et solid hopp tilbake til start.
En engstelig sjel i salen som prøvde å varsku om sikkerhets- og ytelsesproblemer fikk klar beskjed fra podiet: Toget har gått; standarden er vedtatt, framtiden er her og nå.
Så fikk vi se og høre Quake 2, spilt i nettleseren. Wow.
Trend #3 : Weboptimalisering
Ytelsesoptimalisering av websider gir høyere kundetilfredshet, økt konverteringsrate, mer aktive brukere – OG det er lønnsomt ift reduserte krav til infrastruktur og drift.
For å ta det siste først: Siden det å servere ut html-sider er noe av det tyngste infrastrukturen din gjør, har tjenester som Netflix og Shopster redusert henholdsvis antall servere og båndbredde til det HALVE ved å drive strukturert og helhetlig optimalisering av websidene. Sjekk ditt eget driftsbudsjett for å se hva gevinsten kunne vært? Forutsetningen for en slik kostnadsreduksjon er selvfølgelig at man har et stort antall brukere – og at man betaler for faktisk bruk av infrastrukturen (slik man gjør i skyen…).
Google og Yahoo! har foretatt undersøkelser med brukere som blir utsatt for dårlig ytelse. Begge undersøkelsene utsatte brukere for høyere og høyere forsinkelse i levering av websider. Undersøkelsene ble ikke framlagt, men en viktig lærdom fra Google sin undersøkelse er verdt å merke seg:
Google kjørte undersøkelsen med testgruppe og referansegruppe, der referansegruppen ikke ble utsatt for forsinkelser. Testgruppens adferd endret seg, i form av at brukerne ble mer passive, mindre villige til å fullføre oppgaver (=lavere konverteringsrate). Etter at forsinkelsen ble fjernet hadde gruppene fortsatt ulik adferd – i lang tid. Så lang tid at testgruppen ikke hadde fått gjenopprettet sitt aktivitetsnivå idet undersøkelsen ble avsluttet. Brukere som blir utsatt for forsinkelse blir passive, og det gir ingen umiddelbar effekt å rette feilen.
Ved dårlig servicenivå gjør man skade som varer lenge.
Virksomheter som har hatt suksess med weboptimalisering sier at verktøyene ikke trenger å være veldig sofistikerte. De trekker fram Yahoo! YSlow og Google Page Speed som gratiseksempler. Men et viktig suksesskriterie er at ytelsesparametrene ikke kan eies av IT alene: Alle de viktigste ytelsesparametrene må eies (og forstås) av forretningsenheter, markedsavdeling og ledelse. Først da kan man ta ut den forretningsmessige effekten.
Trend #4 : API’er på godt og vondt
Fra å snakke om mashups er dialogen og diskusjonen nå vendt til realitetene ved å eie, forvalte og bruke åpne API’er. Mantraet fra LinkedIn er: Planlegg godt, gjør ingen feil. Lett å si, men vanskelig å gjøre.
Twitter har hatt store problemer med sin autentiseringstjeneste, og har måttet tvinge brukerstedene av API’et over på ny løsning – rett og slett ved å skru av den gamle på et gitt tidspunkt. Resultatet ble at mange tjenester som baserte seg på twitter sluttet å virke, og feilsøking og feilretting rundt overgangen er fortsatt ikke avsluttet. Litt mer kundevennlige LinkedIn måtte ringe opp alle brukerstedene før de gjorde endringer. God service, men en så stor jobb at det nesten er vanskelig å forestille seg.
Lærdom1: Skal man etablere et åpent API må man betrakte brukerne av API’et som kunder, og behandle dem deretter. Å eie et API er å eie et produkt – lansering må planlegges nøye, og produktets livssyklus må analyseres før det settes ut i markedet.
Lærdom2: Skal man benytte et åpent API må man agere som kunde. Dette innebærer å registrere seg, og forholde seg til løpende dokumentasjons- og programendringer. Man må også ytelsesplanlegge og robustifisere sin egen løsning og kundedialog for situasjoner der API’et kan være utilgjengelig.
Trend #5 : Sosiale medier og CRM
Alle vil vite mer om hvorledes man kan benytte sosiale medier i aktiv bearbeiding av markedet og kundene – med økt salg som formål. Mange vil snakke om temaet, og har kloke ideer til hva man ikke bør gjøre. Nesten ingen har gode mønster/patterns for hvorledes gjøre dette i praksis.
Lærdom: Det er bedre å gjøre noe selv om man ikke ser en konkret og målbar positiv effekt, enn å gjøre ingenting og oppleve en konkret og målbar negativ effekt.
Trend #6 : Vi er alle (agile) webutviklere
Sett i lys av ovenstående trender blir webutvikling og kunnskap om tjenester og teknologier en felles møteplass for forretningsutviklere, systemeiere, markedsførere, designere og utviklere. Ingen kan melde seg ut av denne kunnskapssirkelen og fortsatt ha et realistisk håp om fantastiske resultater ved bruk av digital teknologi. Web 2.0 tilhører ingen rolle, avdeling eller virksomhet alene.
For å skape god effekt med mange involverte parter, satte konferansen søkelyset på hurtigd/agile/lean prosesser der man skaper verdi tidlig – og prioriterer hardt i forhold til egne krav. Levere lite & fort er bedre enn mye & sent.
Alt satt i system
I et forsøk på å sette disse trendene i en form for et system, skisset jeg raskt opp denne figuren på det man bare måtte ha med seg hjem fra San Francisco i mai i år: en iPad. Rundt en tredel av alle konferansedeltakerne hadde et brett, og på forespørsel fra plenumspodiet kom så godt som alle hender i været på spørsmålet: “Hvem har en iPhone?”. Tross denne Apple-dominansen var det slående at sympatien vektet tungt i favør av Adobe i spørsmålet rundt framtiden til Flash. Dette er kanskje også trender, men her har vi satt fokuset på forretningsutvikling på nett:
SAS har lansert “Reiseplanlegger” som de flagger som nyhet på www.sas.no og inviterer oss til å “Søk og bestill din neste reise med vår nye reiseplanlegger”.
Det er jo interessant å se hva store etablerte flyselskaper gjør for å møte konkurransen fra lavprisselskapene og en reiseplanlegger høres jo ut som et nyttig verktøy.
Jeg trenger en billett til Roma i slutten av juli og er svært motivert for å la SAS hjelpe meg med å planlegge reisen.
Møtet med reiseplanleggeren var mildt sagt skuffende.
Dette ser ut til at SAS har oppfunnet en ny og litt vanskeligere måte å bestille billetter på. Muligens for folk som velger reisemål etter alfabetisk rekkefølge? Det finnes kanskje en subkultur der ute som er ute etter selve flyreisen og ikke bryr seg om de ender opp i Alicante eller Alta?
Når jeg prøver meg på å velge Juli i menyen, sklir ukene elegant frem i menyen under og jeg velger den siste. Deretter scroller jeg ned til bunnen av siden der jeg finner Roma og syv ulike priser som jeg regner med at er ukedager…den tredje prisen var bra, jeg regner meg fram til at det er onsdag.
For å være sikker på at SAS og jeg tenker likt når det gjelder uker scroller opp til toppen av siden der ukedagene står, det stemmer.
Deretter scroller jeg ned igjen og velger onsdagen. Et slags tåkelag (eller kanskje det er aske) legger seg over siden, men ingenting skjer. Derfor trykker jeg på onsdagsprisen en gang til. Da forsvinner tåka men, jeg har fortsatt ikke fått bestillt meg en reise.
Jeg trykker på nytt igjen og tåka kommer tilbake, nå scroller jeg opp igjen og, heldigvis, ut av tåka kommer en boks der jeg kan velge hvor mange som skal reise. Jeg velger en voksen og to barn og trykker på vis flyavganger. Denne knappen tar meg til kjente omgivelser, to steg inn i den ordinære bestillingsprossesen hos SAS.
Akkurat i det jeg skal til å bestille ser jeg at avreise er i slutten av september, jeg husker tydelig at jeg valgte Juli. (det viser seg at velger jeg juli som måned får jeg automagisk et utvalg av uker i september å velge mellom…?!)
Juli i SAS-verdenen består av noen uker i september...
Jeg gir opp…
…og ender opp med å kjøpe billetten på riktig dato til 1/10 del av prisen på verdens styggeste nettside Ryanair.com.
Ordet “askefast” ble vist nok oppfunnet for fem dager siden. På Google har Colorline, som leverandør av et alternativ til fly, rukket å ta eierskap i søkeordet “askefast”.
Så, du skal ha deg en iPad sier du? Kan knapt vente til den kommer ut? Vel, gru deg i stedet.. For verden trenger ikke en ny gadget, og særlig ikke denne. Her er hverdagen med iPad:
Jeg sitter og utforsker min flunkende nye gadget, og husker presentasjonsvideoene der Steve Jobs prøvde å se uanstrengt ut mens han holdt iPaden i én hånd og navigerte med den andre: Som om han demonstrerte en støvsuger som sugde som aldri før, men veide 100 kg og var fullstendig umanøvrerbar.
.. Nå skjønner jeg opphavet til Steves ansiktsuttrykk i disse videoene: Etter ti minutter har jeg nemlig et lignende et selv; jeg er blitt nummen i grepet, armen min verker og kjennes ut som den skal falle av, så jeg legger iFjøla i fanget.. Men den ligger ikke i fanget slik laptoppen min gjør, den ligger der bare flatt og butter hjelpeløst mot knærne mine. Jeg har lest at det finnes sittestillinger som fungerer, så jeg begynner å eksperimentere, og etter en halvtime har jeg kommet frem til noe som muligens kunne interessere Yogainstruktøren min.
Stuebordet blir neste sted for utprøving, og der fungerer den helt fint. Skjermen synes godt selv om jeg ser den på skrå nedenfra.. Helt til jeg setter på en film, og alle skuespillerne ser overvektige ut pga synsvinkelen. Et anfall av nostalgi kommer over meg; jeg minnes perioden da widescreen var nytt. Den blanke iPad-skjermen er også blitt fettete etter at jeg tidligere på dagen kombinerte et måltid kyllingvinger med litt lett websurfing.
Så der sitter jeg; prøver å få med meg handlingen i filmen med alle de feite folka, ettermiddagssola speiler seg i skjermen og suges inn i kyllingfett-fingeravtrykkene mine, og ryggen verker etter alt utforskningsarbeidet med sittestillinger.
Jeg vurderer å stable noen bøker for å støtte paden opp på høykant, men gir i stedet opp filmen. Min nyervervede gadget skuffer meg, og jeg vil blogge om det, har vaska meg på henda og tørka av skjermen, og er nå klar for å skrive touch på det lille iPad tastaturet. Etter å ha brukt ti minutter på å skrive en linje tekst, gir jeg opp også dette. Følgende har jeg dog klart å knote ned: “iPad er en flopp”, med hele tre utropstegn etter (jeg rakk ikke løfte fingeren i tide). Før jeg lukker nettleseren, stusser jeg over hva alle de små blå legoklossene er; der hvor det pleide å være video, animasjoner og denslags.. Men jeg ofrer det ingen videre tanke..
Frisk luft gir ofte et klarere hode, så jeg bestemmer meg for en tur i parken, blir stående og lure på hva jeg skal ta med meg: Laptop, iPad, iPhone, hoppetau.. eller kanskje bare en bok. Ny dings vinner soleklart foran gamle, men den går ikke akkurat i lomma, så laptop-bagen finnes frem, en MacBook Air fjernes, og iPaden legges oppi. Idet jeg slenger den over skuldra frydes jeg over at den er en hel halvkilo lettere enn med laptopen i, og at jeg sikkert ikke skal skrive noe, og derfor ikke trenger tastatur. Solen skinner og jeg er spent på hvordan skjermen tåler dette. Jeg har en bok jeg begynte å lese på Kindle, men denne tilbakestående dingsen som jeg trodde var en nyvinning (men det går jo ikke an å se film på den engang.. og hvem bryr seg om batterilevetid), den gikk i søpla samme dag som iPad gjorde entré..
Så der sitter jeg i parken, og tenker at det egentlig er ganske ok å bare se på vannsirklene som dannes i fontenen, duene som gomler kebabrester og heroinistene som står i hockeystilling og svaier i vinden..
Jeg fikk nettopp en litt ubehagelig opplevelse i forhold til twitter. I dag ble jeg addet av Dolly Dimple Pizza.
Jeg er ikke særlig fornøyd med å ha Dolly Dimple's Pizza som follower.
En ting er å bli lagt til av mer eller mindre lettkledde damer som du (dessverre) ikke kjenner personlig, en annen ting er å bli lagt til av et firma du har hatt kontakt med og hvor de har lagret opplysninger om deg. Det ene er spam, mens det andre er kun misbruk av personopplysninger på en ufin måte.
Jeg er i utgangspunktet ikke opptatt av å ha flest mulig followers slik at jeg prøver å blokkere de som følger min profil som åpenbart ikke har interesse av å lese det jeg twitrer om. Noen ganger lurer jeg også på om jeg burde ha sperret alle engelskspråklige som legger meg til, siden jeg stort sett twitrer på norsk, men jeg har latt det passere.
Ja, jeg innrømmer å ha kjøpt pizza fra Dolly Dimple og jeg har antakelig krysset av på en eller annen vilkårstekst som sier at de kan bruke informasjonen de har på meg til hva de måtte ønske – hvem leser vel vikårstekstene før de godkjenner innholdet? Som regel er jo disse tekstene så lange at man må både ha en grad i jus fra universitetet til å forstå den og tålmodigheten til en frimerkesamler for å lese igjennom hele teksten. Dolly Dimple har sikkert alt på det tørre når det gjelder de juridiske sidene her. Det er jo også slik at det er DE som følger meg og ikke omvendt.
Jeg har vært på internett siden 1995. NRK har vært på internett siden 1996. Sammen har vi vært igjennom mye rart, fra <blink>-tagger via the single pixel gif til dagens myriade av AJAX, HTML5, CSS3 (hvis du bruker Opera ihvertfall) og andre mer eller mindre etablerte standarder. Det er bare en eneste regel som har overlevd tidens tann, nemlig det sunne og fornuftige mantraet om at man ikke kan ha æ,ø eller å i adressen til websider.
Og heldigvis, sier nå jeg. Det skulle tatt seg ut hvis jeg kunne skrive nrk.no/østlandssendingen (eller bare /østland), når det egentlig er P1-bastionen Ostlandssendingen jeg skal ha tak i. Eller Sørlandet. Eller Bodø. Eller Orkanger, Bergen, Tørdal, Brandt og så videre..
Ok, ironi og gamle referanser til side; Det er altså INGENTING som hindrer nettsteder i å ha normale norske bokstaver i URLene sine, bortsett fra i domenenavnet. Det er både lov og mulig og i høyeste grad anbefalt. Det kan hende at nettleseren din velger å oversette de norske tegnene til noen mye brukervennligere %F20-aktige kombinasjoner men dette begynner også å gi seg etter som nettleserne etterhvert passerer stemmeskiftet og blir voksne (i den grad det er noe tegn på at man er voksen). Mao: http://www.nrk.no/østland er en helt fin URL som jeg vil tro må være lettere å huske enn nevnte /ostland, selv om de sier ostland på radioen hver gang de vil ha folk inn på nettsidene.
De eneste nettbrukerne dette blir problematisk for, er alle som sitter på nettcafè i utlandet med kun spanske eller greske taster tilgjengelig. De må selvfølgelig få lov å komme frem ved å skrive /ostland, men for norske nettsteder med overvekt av norskspråklige lesere, så bør dette være unntaket snarere enn regelen. Det er vel enklere å lære de som behøver det, å bytte ut æ og å med a, og ø med o.
I tillegg synes jeg at brukerne skal få lov til å gjette adressen til den siden de er ute etter. Jeg ser ikke poenget med å prøve å oppdra leserne til å bruke den ene korrekte adressen til en side. Dette minner om et nettsted som er designet for å passe organisasjonen det beskriver, ikke publikum som bruker siden. På Apple sine nettsider kan jeg skrive inn hvilket som helst av ordene jeg forbinder med Apple og bli sendt til riktig side, selv om jeg ikke har truffet riktig URL. De har mao. gode aliaser som sender brukerne videre til riktig adresse. Hvis jeg f.eks. skal laste ned Itunes på norsk, skriver jeg apple.no/itunes og blir sendt til http://www.apple.com/no/itunes/. Siden jeg bruker en av disse voksne nettleserne (Safari for øyeblikket) så slipper jeg tilogmed å skrive http i starten av nettadressen, det er også et pluss.
404-sider er det siste punktet jeg kunne tenke meg å gjøre noe med. Disse opptrer som regel når noen har fulgt en gammel lenke, eller prøvd å være “smarte” ved å ta sjansen på at den URLen man har skrevet inn, er den rette. Jeg synes at ingen av disse tilfellene holder som gyldig grunn til å sende brukeren til 404-siden.
For det første, lenkene dine (dvs. nettadressene til innholdet ditt) må ikke inneholde spor av webrammeverket du bruker. Http://www.vg.no/artikkel.php?artid=5826064 er for eksempel ikke bra. Dette knytter VG for “evig og alltid” til php som implementasjonsrammeverk, og hvis du skal huske en ting fra dette innlegget så er det at PHP er ikke et rammeverk du vil være knyttet til spesielt lenge . Alternativt må nettstedet vedlikeholde mappinger mellom artiklers opprinnelige nettadresser og adressene de har i nettstedets nåværende publiseringssystem. Det er helt unødvendig at det må være slik, men det virker som om dette ikke har nok fokus i mange publiseringssystemer.
Som en siste foranstaltning for å unngå 404-sider så foreslår jeg at du gjør et søk på det som står i tittellinjen, etter domenenavnet, dersom du ikke kan finne ut at adressen som er skrevet inn, peker på et bestemt innhold. Dette er også forholdsvis enkelt å implementere, du må bare ha en “catch-all” funksjon til slutt i oversettelsen mellom URL og innholdsside, som kan starte søket. Tenk hvor fint det hadde vært å kunne skrive www.vg.no/Bjørn Dæhlie (med mellomrom OG æ og ø, ja!), og få opp et søketreff om en av Norges største idrettsmenn, istedenfor en 404-side bare fordi VG ikke har noen redaksjonelt sammensatt side om mannen?
En kort oppsummering som bonus til dere som har kommet dere helt hit:
Jeg vil ha følgende nettadresser implementert skikkelig:
http://www.nrk.no/østland
http://www.nrk.no/østlandssendingen
http://www.vg.no/film/mel-gibson-blir-pappa-igjen
http://www.vg.no/Bjørn Dæhlie
Det er nå en stund siden jeg har sett reklame på nett. Takket være diverse plugins til Firefox og andre moderne nettlesere, kan jeg skru av alt som plager meg. Her om dagen kom jeg imidlertid borti feil knapp, og vips ble jeg bomba av banner-ads. Jeg leste nyheter da dette uhellet inntraff, og eksempelet fra Aftenposten (ikke for å henge ut noen. De er vel hverken er bedre eller verre enn andre norske nettaviser) nedenfor viser hva jeg ble utsatt for. Banneret i bunnen fra Sparebank1 er spesielt interessant: Det ligger limt i bunnen av nettleserviduet, og følger meg hvor enn jeg scroller. Stilig! Tommelen opp til vedkommende som tenkte ut denne løsningen for ekstra-irritasjon-via-HTML-triksing.
Jeg tok også en skjermdump etter at jeg hadde skrudd reklamen av igjen.. Bare sånn for å sammenlikne.
Det finnes mer behagelige eksempler der ute, bl.a times.com/ , hvor de ser ut til å ha streng kontroll på hva som tillates av bannere. Resultatet er en behagelig side, hvor jeg orker å oppholde meg lenger.
Det er få som vil ha reklame. Bl.a undersøkelser fra papirverdenen* underbygger dette. I Bergen har de innført en løsning hvor man aktivt må takke ja hvis man vil ha reklame i postkassa. I Oslo popper det opp flere og flere “Nei takk til reklame” klistremerker. Jeg gjorde en test i oppgangen der jeg bor; jeg bestilte en bunke slike klistremerker, klistret opp ett selv, og la resten til fri disposisjon for naboene mine. Resultatet var naturligvis at omtrent samtlige klistret en lapp på sin postkasse også.
For papirverdenens del, er det også naturlig nok miljøhensyn involvert; man kan redde trær osv. Miljøhensyn er dog sannsynligvis ikke hovedmotivasjonen til å takke nei.
Det har dukket opp diverse måter å beskytte seg mot reklame i ulike kanaler; også per SMS (såvidt jeg vet ulovlig uten samtykke) E-post, Telefonsalg, etc.
TV står igjen som en av de mer problematiske.
Når det gjelder nettsider, er et viktig spørsmål: Når / hvis ad-blocking blir gjort enkelt og tilgjengelig nok for den gjengse bruker, hvem gidder å se reklame lenger?.. Hvis det plutselig var en tydelig knapp i nettleseren som sa “skru av reklame”.
Ikke at jeg tror at en slik knapp noengang vil dukke opp, men det hadde vært fint
Vi vet det er mange som går med tanker om hva sosiale medier kan gjøre i en kommersiell sammenheng. I denne sammenhengen har vi i Tarantell fått en innsikt i hva brukeranbefalinger betyr for trafikken på et nettsted.
Figuren viser trafikktallene for denne bloggen: Vi har et jevnt og hyggelig besøk (som ikke er alt for imponerende). Og når kollega Øyvind Haagensen i juni får en omtale av ett av sine blogginnlegg på Din Side Økonomi, ser vi at besøkstallet for denne dagen er omtrent det dobbelte av vanlig. 64 treff noterer vi oss den 19. juni.
Når kollega Haakon Halvorsen kritiserer Politi.no og gjør en liten innsats for at budskapet skal spres via Twitter, får vi derimot en enorm trafikkvekst. All time high på over 10-gangeren av hva vi pleier å ha av daglige besøk, med hele 733 besøkende denne dagen.
At mennesker stoler mer på anbefalinger fra andre mennesker enn fra media, det visste vi. Men at forskjellen skulle være så stor var en interessant nyhet for oss – og kanskje for andre?
Jeg skal ikke prøve meg på å gi fasiten på alt Twitter skal og kan brukes til her og nå. Men for dem som er interessert i hva kommersielle aktører kan gjøre for å fange et publikum, så anbefaler jeg å ta en titt på hva Stokke® (@StokkeLovers) gjør for sine kunder.
. Alternativt må nettstedet vedlikeholde mappinger mellom artiklers opprinnelige nettadresser og adressene de har i nettstedets nåværende publiseringssystem. Det er helt unødvendig at det må være slik, men det virker som om dette ikke har nok fokus i mange publiseringssystemer.
