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:

Kundeopplevelse og Web 2.0 trender

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

Tyskerne krever 945 piksler for at de skal kunne innarbeide det gylne snitt, men portugiserne står hardnakket på 925 og har allerede begynt å implementere… hva skal jeg gjøre? Hva er riktig?

Utsagnet oppsummerer kundens situasjon: Stor organisasjon med regionale aktører og egne meninger på kollisjonskurs med behovet for et enhetlig og konsistent design. Kunden har innsett at det sistnevnte gir både kommunikasjonsmessige og økonomiske gevinster, men får problemer i møte med tilsynelatende vilkårlig valgte tall som det plutselig er gått nasjonal prestisje i.

La oss passere nasjonal selvfølelse i stillhet: Hvordan velger du egentlig optimal bredde på en nettløsning? Svaret er, som med mye annet i livet, at det kommer an på. Heldigvis kommer det ikke an på så fryktelig mye, og vi skal se på det viktigste her.

Fast eller fleksibel

Høyde

Med unntak av statiske online-reklameplakater, microsites, kampanjer og en og annen webapplikasjon, har nettsider som oftest fleksibel høyde. Denne utformingen rommer mulighet for variable mengder av innhold i form av tekst, bilder og andre media, og forskjellig presentasjon av dette materialet avhengig av kontekst. Scroll-hjul på musen har gjort det helt naturlig å flytte siden oppover etterhvert som man skummer gjennom en artikkel eller skaffer seg oversikt i en portal – faktisk er det ofte langt mer irriterende å måtte “klikke for å gå til neste side” enn bare å la siden gli over skjermen. Personlig mener jeg at med unntak av ved svært store datamengder eller ved behov for å eksponere brukerne for stadig nye bannerannonser er sideskift uten et samtidig skifte av kontekst eller tema en uting på internett.

Bredde

Når det gjelder bredden har man i utgangspunktet 2 valg: Fast eller fleksibel bredde. Det er fordeler og ulemper ved begge disse. Ikke alt innhold egner seg til fri skalering i bredden, men dette får bli gjenstand for et annet blogginnlegg. Det er ihvertfall stadig diskusjon om hva som fungerer best i de enkelte tilfellene, og Dagbladet hadde nylig en artikkel vedr. nettavisens redesign til å bruke fullskjermbredde uansett skjermstørrelse. Men uansett hva du velger må du finne den optimale størrelsen eller minste-størrelsen for nettsiden din. Hva som er riktig størrelse kommer an på både tekniske og kommunikasjonsmessige forhold:

Sjekkliste for å finne optimal nettsidebredde

Denne listen starter med spørsmål som er almenngyldige for alle designprosesser og blir mer direkte relevant etterhvert. Kommunikasjonskanalen er i dette tilfellet er bestemt: Internett.

1. Hvem snakker du med?

God kommunikasjon avhenger i stor grad av kjennskap til hvem man snakker til eller med. Ha et klart bilde av hvem du forsøker å nå – hvem skal bruke nettsidene dine, hva skal de oppnå, hvilke forutsetninger har de, osv. Med en nettstrategi i ryggen kan du gjerne bruke  personas eller andre verktøy for å etablere gode, klare svar på dette.

2. Hvilken fysisk skjermbredde har de?

Det som ofte veier tyngst i å avgjøre nettsidenes bredde, er hvilke tekniske forutsetninger brukerne har for å se sidene – mao. hvilken skjermbredde og skjermhøyde de ser løsningen med. Dette er det mulig å svare mer eller mindre presist på:

1. Dersom nettsidene skal utgjøre et intranett i en stor organisasjon med en IT-avdeling med rutiner som får “Prosessen” av Kafka til å blekne er svaret ofte veldig enkelt og veldig presist: Alle har akkurat samme skjerm med akkurat samme oppløsning. Uansett. I slike tilfeller har alle forresten også samme nettleser – det gjør det i teorien lettere å utvikle spesialfunksjonalitet til intranettet – men ikke sålenge nettleseren heter Internet Explorer 5 – kom igjen folkens: Oppgrader!
2. Dersom nettsidene retter seg mot offentligheten må vi istedet gjøre antagelser basert på hva vi vet om brukerne. Vi kan undersøke forhold som f.eks. deres brukssituasjon (hjemme eller på jobben?), yrke (grafisk designer eller lokomotivfører?), interesser (ornitolog eller power-gamer?), og andre demografiske data for å si noe om nivået på deres typiske IT-investering.
3. Sist men ikke minst kan vi basere oss på eksisterende nettstatistikk for brukere av tjenester som har lignende profil som den man selv skal lage. Fordelingen av brukere på skjermoppløsninger i løpet av første halvdel av desember for 2 store norske internettjenester med svært bred publikumsappell var som følger (grunnlaget baserer seg på mellom 2 og 3,5 millioner unike treff, og oppløsninger med samme bredde er slått sammen til ett tall):
   

   Oversikt over skjermstørrelser for unike besøk på 2 store norske nettsteder 2 uker medio desember 2008

   Tallene viser at det er forskjell på hva folk benytter på jobb og hjemme, og viser også at det brede laget av befolkningen i alle situasjoner besitter et minimum på 1024 x 768 piksler.

3. Hva er den maksimale bredden?

Med en skjermbredde som er rimelig ifht. brukernes forutsetninger må vi finne ut hvilken bredde vi egentlig har til rådighet. Poenget er å ikke definere en så bred side at man får horisontal rullesjakt* når nettleservinduet er maksimert og har vertikal rullesjakt. Forskjellige operativsystem og nettlesere “spiser” litt forskjellig av den totale skjermbredden til å vise nettleservinduets kanter og den vertikale rullesjakten. Som en tommelfingerregel bruker vertikal rullesjakt 16 piksler i bredden. I tillegg bruker enkelte nettlesere opp til 8 piksler på hver side for å tegne kanten på nettleservinduet. Dermed går altså 8+8+16 = 32 piksler i utgangspunktet tapt i bredden. På en typisk skjermoppløsning på 1024 x 768 sitter vi da igjen med en maksimalbredde på 1024 – 32 = 992 piksler.

Hva da med brukere som har installert/aktivert tilleggsmenyer i nettleser/operativsystem som også tar opp verdifull plass i bredden? På Windows dreier dette seg  primært om en “sidebar” i Vista (som Google har laget et alternativ til). På Mac er det mulig å plassere Dock’en på høyre eller venstre side og sette den til å ikke automatisk skjules. Dette spiser verdifull skjermplass. Skal vi ta hensyn til brukere som gjør dette? Med forbehold om spesielle forhold ved nettsidenes funksjon vil jeg stort sett svare nei. En bruker som bevisst endrer oppsettet så det avviker fra standardoppsettet er klar over at dette er gjort, samtidig som slike brukere statistisk sett er del av et svært lite mindretall. Det er også rimelig å anta at slike brukere med stor sannsynlighet ikke sitter med den minste tilgjengelige skjermstørrelsen heller – og da er det uvesentlig om 30-40 piksler ekstra går tapt.

(*”Scroll-bar” heter faktisk “rullesjakt” på norsk. Som innvandret brite får jeg gåsehud av begreper som dette, men forsøker altså å holde språket norsk her. Uoffisielt forslag for “roll-over” er forresten “Overglidning”. Brrr.)

4. Bruksmessige hensyn

Hvordan nettsidene skal fungere, dvs. hva deres oppgave er ifht. brukeren samt hvilket etterlatt inntrykk brukeren skal sitte igjen med, er en minst like vesentlig faktor som fysisk og virtuell skjermbredde. I enkelte tilfeller dikterer hensynet til nettsidenes funksjon hvilken skjermstørrelse man skal optimalisere nettsidene for, fremfor at minste felles multiplum for skjermstørrelse skal gjelde slik at “alle” kan se sidene optimalt.

Big is always beautiful

Det er ingen absolutte regler for hva slags type side som bør ha stor eller liten plass. En portal eller nyhetsside “trenger” i utgangspunktet mer plass i bredden enn en blogg: Dette er sideoppsett som gjør aktiv bruk av flere spalter og seksjoner for på en visuell måte å prioritere store mengder informasjon. Likeledes vil en side som skal fungere som arbeidsflate – som et intranett dashboard eller en webapplikasjon – ofte nyte godt av større plass. Men selv en blogg eller en kampanjeside bruker stor skjermplass med fordel – innholdsområdet kan utformes smalt eller lite, men ekstra plass rundt innholdet skaper ro og fokus på budskapet.

Jeg kommer ikke på noen tilfeller der nettsider har en stor fordel av å være små (vi snakker nettelsere og skjermer, ikke wap og håndholdte devices nå). De tilfellene finnes nok, men i min verden blir dette i større grad en designmessig avveining – det er alltid gunstig å ha stor plass å boltre seg på, og hvis det innenfor rammen av tilgjengelig skjermbredde ikke er noe ved bruksegenskapene som tilsier at sidene bør ha liten bredde kan hele flaten gjerne gjøres tilgjengelig for formgivning – enten det endelige arbeidet oppfattes som avgrenset innenfor et rolig passepartout eller ikke.

5. Hvordan dele opp flaten?

Vi har funnet skjermstørrelsen vi ønsker å basere oss på og har trukket fra nok til å gi oss en sikker maksimumsbredde. Hvordan bestemmer vi om den endelige bredden optimalt skal være 992 eller f.eks. 945 (som i eksempelet med det gylne snitt) eller 925 piksler? Dette er et designspørsmål, og her kommer designerens beste venn – grid’et – inn i bildet.

Grid

Et grid er i all enkelhet et rutenett med en konstant avstand mellom alle vertikale og alle horisontale linjer. Poenget med grid er at man benytter det som et skjelett å bygge designet på – man sørger for at vesentlige visuelle elementer går kant i kant med linjene i grid’et. På denne måten oppår man ryddighet og stramhet i designet – det at forskjellige elementer flukter med hverandre på tvers av formatet skaper ro og klarhet. Et grid kan ha store eller små ruter – mindre ruter gir i utgangspunktet større fleksibilitet. Et grid er ikke en tvangstrøye: Grid’et kan brytes bevisst for å oppnå en ønsket effekt. Dette er grunnleggende designkunnskap, og Khoi Vinh og de fine folkene på A List Apart har laget artikkler som viser bruken av grid på en kjempebra måte.

Eksempel på side som bruker grid

Eksempel på side som ikke bruker grid

Som du sikkert allerede har gjettet – størrelsen på rutenettet i gridet, kombinert med hensyn til hvor mange og brede spalter man ønsker i sideoppsettet, avgjør hva som er en hensiktsmessig pikselbredde for nettsiden. Noen eksempler belyser dette best:

3 eksempler på utregning av sidebredde

Hvilket antall kolonner og hvilken bredde/høyde på hver grid-rute som er riktig for nettstedet eller de enkelte sidene i nettstedet er en vurderingsak i hvert tilfelle. Dette er et puslespill hvor man gjerne tar hensyn til:

• Hva og hvor mye skal med på en gitt nettside? (Informasjonsarkitektur)
• Er det forhåndsbestemte mediaelementer som skal fungere i grid’et (f.eks. video eller reklamebannere i standardstørrelser)?
• Hvilken gridstørrelse er formålstjenlig ifht. formspråket – er det lettere å sette opp sidene med mindre ruter eller større ruter?

Personlig liker jeg å jobbe med grid som baserer seg på tall som er lette å dele på hele antall piksler, f.eks. 32 som lar seg dele på 2, 4, 8 og 16, eller 24 som lar seg dele på 2, 3, 4, 6, 8 og 12. Når og hvis omstendighetene tilsier at grid’et skal brytes blir det på denne måten lett å gjøre det på en måte som harmonerer med grid’ets basistall.

Grid er forøvrig ikke bare til hjelp som et verktøy for design. Det finnes flere rammeverk i CSS som gir støtte for svært effektiv implementasjon av nettsider ved bruk av grid. Et godt eksempel er Blueprint CSS som lar deg definere et grid i tråd med det du har benyttet ved design av nettsidene, og som deretter genererer CSS som enkelt lar deg posisjonere elementene i forhold til dette grid’et.

Det gylne snitt

Vi har funnet optimal bredde for nettsiden vår, og definert et bra grid vi kan jobbe med. Men hva var egentlig det snakket om det gylne snitt i starten av innlegget?

Det gylne snitt er et forholdstall som har lang historie innen arkitektur, kunst, design og musikk. Mange menneskeskapte verker bærer i seg det gylne snitt, og tallet finnes også igjen i mange former i naturen. Det gylne snitt defineres ved at man deler en linje i en lang og en kort del, hvor forholdet mellom den lengste delen og den korteste delen er det samme som forholdet mellom hele linjen og den lengste delen av linjen. Wikipedia har en forklarende artikkel.

Jeg ble overrasket over referansen til det gylne snitt i kontekst av nettsidebredde. Det er tradisjonelt et begrep som hører mer til design for papirtrykk enn for piksler. Når det er sagt er det er ikke noe galt i å forsøke å innarbeide dette prinsippet, men det virker nokså tynt å skyve det foran seg som en forklaring på hvorfor man akkurat måtte bruke 945 piksler, særlig når man ikke kommer inn på hva 945 skal stå i forhold til. Det gylne snitt er et interessant forholdstall som kan gi vakre proporsjoner. Det er et virkemiddel som kan vurderes brukt på samme måte som andre virkemidler – ikke et slags komposisjonsmessig dogme som må etterkommes for enhver pris og uten spørsmål. Et godt grid vil stort sett gjøre mer for kvaliteten enn det å innarbeide det gylne snitt for ett eller flere forhold på nettsiden din.

Uten mulighet til selv å ta tak i formgivningen som var utført for kunden anbefalte vi på generelt grunnlag å benytte den største av de to skjermbreddene som det allerede var sunket tid og penger i å utvikle,  basert på prinsippene vi har vært innom her. I og med det tyske kontoret dermed har fått viljen sin får vi håpe at også det gylne snitt vil bidra til å heve det ferdige produktet.

Vi har laget 4 PDF-er med uvurderlig informasjon til deg som driver med sånt som vi driver med, nemlig HTML/CSS, SEO og SOA.

Kan du riste av deg en 3-kolonners flytende sidelayout uten å bruke tabeller? Visste vi det ikke.

Har du full kontroll på hvordan elementene flyter på siden din? Hva med den høyrejusterte søkeboksen øverst? Hvordan har du tenkt å ordne den? Akkurat, ja.

SEO, hva tror du der? Er dere så høyt oppe på Google som dere skulle ønske? Ikke? Hmm..pussig

Heldigvis har du ihvertfall SOA-kunnskapene dine å falle tilbake på. Eller? Kan du ramse opp? Kanskje du bør lese videre da…

3-kolonners layout uten tabeller

Ofte omtalt som “The Holy Grail of web layouts”, dette er noe enhver som skal sette opp websider må kunne. I gamle dager ordnet man seg med tabeller og fiffige 1-pixel-finter for å spenne opp siden med riktige bredder på topp, sidemeny og hovedinnhold. Nå om dagen holder ikke dette, og vi har laget en liten jukselapp for deg som trenger et sted å begynne.

3-kolonners-layout.pdf (315 kb)

Floating og posisjonering av HTML-elementer

Basiskunnskap for å kontrollere flyten av innholdselementer på sidene. Denne jukselappen gir deg det du trenger for å begynne å eksperimentere med riktig posisjonering ved hjelp av CSS, uten å henfalle til tabeller og denslags.

floating-og-posisjonering.pdf (132 Kb)

SEO – søkemotoroptimalisering

Her lister vi opp de viktigste prinsippene for å gjøre brukerne (og dermed Google) fornøyde med nettstedet ditt. Det viser seg at URL-er av typen /page.php?articleId=25645&section=234&JSESSIONID=$123%A483f382ds478289347 ikke er høyest ansett, hverken av brukere eller søkemotorroboter. Men når du kan krysse av punktene på denne sjekklisten, bør mye være gjort.

seo-sjekkliste.pdf (146 Kb)

Prinsipper for tjenesorientert arkitektur (SOA)

Hva er egentlig SOA? Sånn egentlig-egentlig? Her finner du prinsippene som definerer en god tjenesteorientert arkitektur og som kan brukes som en sjekkliste for å verifisere om din egen organisasjons SOA er på stell.

soa.pdf (99 Kb)

Derfor ble jeg veldig glad da jeg kom over Elastic Paths blogg-innlegg om ”Ecommerce Innovations” der de tar for seg mange forskjellige nytenkende framgangsmåter i forskjellige kategorier innen ehandel. Spesielt dette med videopresentasjon av produkter fenget meg. Blogg-innlegget er basert på et webinar som blir lagt ut i nærmeste framtid, og anbefales i sin helhet. Her er noen av eksemplene fra bloggen som jeg likte spesielt:

Martin + Osa har en spennende måte å vise produktpakker på – ”Shop by outfit”. En modell viser hele antrekk for forskjellige settinger. En vidosnutt viser modellen som snur seg rundt og viser antrekket fra alle vinkler. Man kan velge å handle antrekket i sin helhet eller kun enkelte av plaggene, og man får velge størrelse og farge på hvert plagg man ønsker.

Den samme butikken har også en annen spennende måte å selge produktpakker på – “layer your own look”. Her kan man kle på sin egen utstillingsdukke, legge på klesplagg for klesplagg og sette sammen et helt antrekk som man enten kan sende til en venn på e-post eller kjøpe. Man får da opp alle produktene i en liste med mulighet for å velge størrelse og farge på hvert enkelt plagg.

Knicker picker selger undertøy for kvinner, og har valgt å legge vekt på en veldig levende presentasjon av sine produkter. Her velger man først en modell i ønsket størrelse ut fra enten øyemål eller faktiske mål (i mouseover) – en perfekt måte for menn å velge undertøy til dama på uten å huske alle disse vanskelige målene? Man kler så opp denne modellen i ønsket truse, bh, sportsundertøy, natt-tøy eller badetøy. For å gi et bedre inntrykk av hvordan undertøyet tar seg ut på modellen, kan man få henne til å gå fram og tilbake, snu seg rundt – og i sportsundertøy til og med jogge litt! For personlige produkter som det ellers er vanskelig å få inntrykk av ut fra et bilde er dette en veldig beskrivende framstilling av produktet, og gutta syntes selvfølgelig dette var veldig underholdende..

Gap har også valgt å vise sine jeans i videoformat. Her ser vi hvordan de forskjellige buksene ser ut på og i bevegelse, som gir en mer reelt inntrykk av produktet enn i de tradisjonelle stillbildene.

Jeg ble i alle fall inspirert til å shoppe litt nå..

Se hele webinaret hos Elastic Path: http://www.elasticpath.com/events/innovation/

Nuvel. Vi i Tarantell, som utviklere av nettløsninger, er nødt for å holde oss oppdatert om trender og retninger på nett. Og den kanskje hyggeligste trenden om dagen, er at internett går tilbake til røttene. Og da snakker vi helt tilbake til port 80 eller der omkring. Dette vil si at de standardene som ligger til grunn for internett, blir viktigere og viktigere å følge. Så på en måte kan vi si at web 2.0 (som ligger ute nå), har en mye bedre forankring i den opprinnelige wwwebben enn det web 1.0 hadde. Web 1.0 dreide seg i stor grad om å forsøke å omgå eller ikke ta hensyn til disse konvensjonene. JSF og .NET-rammeverkene som fremdeles er hhv. Sun og Microsofts anbefalte plattformer, er gode eksempler på dårlig bruk av internettstandarder. Jeg skal gå i detaljer om dette emnet ved senere anledning, denne gangen ville jeg bare opplyse om et tillegg til Firefox (tillegg heter det ja, bør oppdatere tittellinjen kanskje..) som gjør det enklere å utvikle grid-basert layout. Evt. rutenettbasert (sic) om du vil (jeg vil grid-basert i dag).

Tillegget heter GridFox og er utviklet av Eric Puidokas (se ill.) Dette tillegget gjør det mulig å skru av og på et ferdigdefinert rutenett som legger seg over nettsiden du holder på å utvikle og hjelper deg til å sikre at layout følger de kolonnebreddene du jobber etter. Den kanskje viktigste nettsiden som bruker grid-basert layout, er www.nytimes.com. Layoutsystemet på NY Times er utviklet av Khoi Vinh og dokumentert på hans klassiske blogginnlegg “The funniest grid you ever saw”. Dette er et innlegg som har betydd masse for utviklingen av gode, standard-drevne nettsteder som oppfyller nettets “krav” til god separasjon mellom innhold og utseende, tilgjengelighet for alle brukere (og nettlesere) og flere andre “best practices” for god nettdesign. Firefox-tillegget er gratis å installere (som så mange andre nyttige verktøy), og versjon 1.1 kan installeres herfra.

Oppdatering: Har fikset installasjonslenken sånn at den fungerer (takk for tipset, Haakon).

• Ajax: Telenor produktveiviser. Klikk på “Bestill”-knappen for å starte produktveiviseren.
• Ajax rammeverk: Rico
• Ajax rammeverk: Yahoo User Interface Library. Eksempel på faner der back-knappen virker.
• Flash: Jøtul
• Flex Component Explorer
• Flex: Picnik bildebehandler
• Flex: Buzzword tekstbehandler
• Air runtime og eksempelapplikasjoner
• Silverlight runtime og eksempelapplikasjoner
• Silverlight: Golden Globe
• Java applet: Boids
• Google Web Toolkit: Kitchen Sink
• Google Web Toolkit: Mail

Mozilla er nemlig ikke alene. Adobe Labs har for eksempel lansert sin nye plattform “Air” som gjør det mulig å lage fullverdige desktopapplikasjoner som kan samhandle helt eller delvis med webappliaksjoner. Et eksempel på dette er eBay sin beta desktop applikasjon, hvor man kan betjene hele sitt engasjement på auksjonstjenesten – offline. Så snart man er online vil informasjon fra din desktop syndikeres med den sentrale nettjenesten. Du kan også “surfe” og bruke den ordinære webtjenesten til eBay fra desktop applikasjonen.

Dette er på mange måter en “stille revolusjon”. For forbrukere er dette kun en utøkt service fra tjenesteleverandører vi benytter oss mye av. Tenk deg for eksempel nettbanktjenester utført på denne måten. Men for virksomheter kan de faktiske implikasjonene langt overgå det som ligger i bedre service.

Bedre service er bra, og vil sannsynligvis gi økt inntjening, eller bedre måloppnåelse for de det gjelder. Men enda viktigere er sikkerhetsaspektet. Browsere er ikke laget for sikkerhet, noe alle sikkerhetseksperter er smertefullt klar over. Flytter man applikasjoner til desktopen vil man ha helt nye muligheter til å tilby tjenester hvor man tar i bruk brukernes egne maskiner for å ivareta sikkerheten. Sikkerhetsutfordningene på nettet blir ikke borte ved hjelp av den desktop webapplikasjoner, men vi får et helt nytt sett med muligheter som tradisjonell browserhåndtering aldri vil kunne gi oss.

Og om ikke dette var nok, vil man kunne utnytte lokal prosessorkraft i stedet for å prosessere alt over egne servere. Dette gir mulighet for store innsparinger for virksomheter som tilbyr tung funksjonalitet i sine webapplikasjoner.

Min spådom – og jeg er ikke alene om den – er at desktop webapplikasjoner vil bli utviklet av virksomheter som har en stor masse av brukere som hyppig benytter seg av webløsninger med høye sikkerhetskrav og prosessering av store datamengder. Eksempler på dette kan være meglertjenester, nettbanker, webbaserte effektiviseringsverktøy osv.

Så langt ligger mye av utviklingen på dette området i softwareselskapenes lab avdelinger. Men det vil ikke vare lenge.

Tilgjengelighet på nett har mange navn: ”Universell utforming”, ”design for alle”, ”inkluderende design” og ”tilgjengelighet for alle”. Men ”design for de blinde” er ikke så vanlig som synonym for tilgjengelighet. Tilgjengelighet har altså en større målgruppe enn bare de som er blinde.  For å forstå viktigheten av tilgjengelighet må vi vite hvem som trenger tilgjengelighet. Hvor stor kundemasse lukker vi egentlig døra for når vi bestemmer oss for en løsning som ikke er tilgjengelig?

Det er riktig at synshemmede trenger tilgjengelige nettsteder. Synshemmede er blinde eller svaksynte. Mer enn 1000 nordmenn er helt blinde, og over 130 000 nordmenn er så svaksynte at de ikke kan lese (papir)avisa.

Hørselshemmede har selvfølgelig ingen problemer med vanlig tekst og bilder, men trenger et alternativ der hvor informasjon presenteres som lyd (lydfiler og video). I følge Hørselshemmedes Landsforbund er det 600 000 hørselshemmede i Norge.

Det føres ingen samlet statistikk over antallet funksjonshemmede i Norge. Men ut fra Helseundersøkelsen fra 1985 (SSB) kan vi anslå at 18,8% av Norges befolkning, dvs ca 800 000, er funksjonshemmet.

Om 5 år er 50% av Norges befolkning over 50 år. I 2020 gjelder det samme for hele Europa. De ”nye eldre” er en kvalitetsbevisst og kjøpesterk gjeng som ikke finner seg i å få dårligere tilbud enn resten av befolkningen. 50-åringer skal selvfølgelig ikke defineres som funksjonshemmede, men med alderdom følger det gjerne nedsatt syn, hørsel, grep og bevegelse, i ulik grad og ulike kombinasjoner.

Andre grupper som også kan dra nytte av tilgjengelige nettsider er:

• Folk med lese- og skrivevansker
• Folk som ikke kan flytende norsk
• Folk som bruker gamle nettlesere eller har liten båndbredde på internettforbindelsen.
• Folk som ikke har brukt internett før

Til slutt et sitat fra Norges Handikapforbund:

Funksjonshemmet er ikke noe vi er, men noe vi blir på grunn av samfunnets manglende respekt for mangfold.

Hørt om Ta-da og Backpack? David Heinemeier Hansson hos 37signals er programmereren og evangelisten bak disse applikasjonene. Han er nå leder for videreutviklingen av det ikke helt ukjente rammeverket Ruby on Rails og har svært klare ideer om hvordan utvikling av webapplikasjoner skal foregå.

Etter en obskønt amerikansk intro sparker Hanselman moroa i gang : Må HTML vike for rikere presentasjonsteknologier som Apollo og Silverlight? Hansson tar resolutt til motmæle og omfavner HTML/CSS/JavaScript for begrensningene og konvensjonene det gir. Orginalitet er ikke nødvendigvis en god ting i UI design, de tradisjonelle teknologiene gir både brukere, designere og utviklere kjente modeller å jobbe med. Hansson ser ingen grunn til å finne opp flere hjul. Fowler kunne vanskelig vært mer enig, rike klienter er fint og flott til fancy gadgets, widgets og desktopapplikasjoner men mangler rammene som HTML med venner gir. Folk flest takler ikke friheten som følger med et blankt ark, og dette vil gå på brukervennligheten løs. Verktøy og muligheter kommer i fokus og interaksjonsdesignet havner på sidelinjen. Gode prosesser som forener smidig utvikling og usability er områder som behøver ytterligere fokus ærklærer Fowler og jeg kjenner jeg blir litt rørt.

Designet må komme først og gjerne tett påfulgt av HTML – design er ikke pynting som vi legger på toppen etterpå, men utgangspunktet for applikajsonen. Heinemeier Hansson tror designere tåler litt Ruby kode i HTML’en sin og i tillegg skal man strebe etter å få reelle data på lufta så fort som mulig – “lorem ipsum” må gå. Funksjonelle spesifikasjoner trenger vi heller ikke, applikasjonen er spekken og hvis vi ikke liker den så forandrer vi den, når som helst, og hvor grunnleggende som helst. Fowler stepper inn med presiseringer: Design først, men ikke for mye. Virkeligheten forandrer seg for ofte til at man kan gå tre måneder i tenkeboksen og tegne opp hvert eneste skjermbilde. Man skal utvikle i små steg og være forberedt på endring, nøkkelord her er Enhetstesting og rammeverk. Jeg kjenner at jeg nikker og smiler.

Diskusjonen vender seg mot estetikk i kode og hvordan strengt dogmatiske rammeverk tvinger utviklere til å gjøre ting pent og riktig helt fra starten av samtidig som det avler engasjerte sjeler. For debattdeltagerne er trenden er tydelig: alfautviklere og tilsvarende kunder går bort fra Microsoft og fossefallsmetode til fordel for mer engasjerende metoder og teknologier – med andre ord: Agile og Rails.

Podcasten i sin helhet finner du her:
http://www.hanselminutes.com/default.aspx?showID=82

Namedropped:
Jeff Patton
Marc Mcneill
Treesurgeon
Magic ink manifesto

Fritt sammendratt av
Stephan Winter