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.

“Politiet ble i dag utsatt for ran på høylys dag. De mistenkte stakk av med verdier for 28 millioner kroner og etterlot kun www.politi.no som eneste synlige spor.  Politiet etterlyser i dag en person som utga seg for å være designer, men som etter å ha brukt kun 30 minutter og noe som kan ha vært gamle frontpage maler fra tidlig 90-tallet, forsvant fra åstedet med et ukjent (men høyt) beløp. Vitner sier de så en mann i 19-årene gå ut av politihuset med krampelatter og en koffert som struttet av penger i det han hoppet på mopeden og kjørte avgårde i høy fart.

Videre leter politiet også etter sikkerhetseksperten de leide inn for å sørge for at tips og anmeldelser på nettstedet skulle bli behandlet på skikkelig måte – her har forbryteren kun satt opp noen enkle e-postskjemaer, tatt seg kraftig betalt og gått ut bakdøren.  Alle som måtte ha tips om denne saken bes gå på politi.no og fylle ut tips-skjemaet. Hvis spamfilteret fungerer som det skal så er politiet minst 35% sikre på at tipsene vil komme til rett saksbehandler – før eller senere. Dette er imidlertid hele 20% høyere enn oppklarelsesraten på tyverier så politiet er i god tro om at tipsene publikum sender inn vil komme frem.”

Jeg synes oppriktig synd på Politiet og håper at saken om de savnede 28 millionene vil løse seg, at de skyldige blir funnet og stilt for retten slik at de får sin rettferdige straff.

Dersom ansvarlige for nettsiden hos politi.no føler behovet for å rydde opp i navigasjonsmenyene eller kanskje få et skikkelig design så skal vi i Tarantell gjøre vårt beste for å hjelpe i denne vanskelige stund. Vi vet jo alle hvor ille den forrige nettsiden så ut og hvordan det må ha vært å leve med denne i 8 lange år. Det kan heller ikke være lett for Storberget å legge frem denne “nye” nettsiden nå som det er snart er valg og greier.

Våre designere og interaksjonsdesignere har (så vidt vi vet) plettfri vandel, og ingen kjører moped, så det skal nok gå helt fint.

Vi vil ta politi.no i nærmere ettersyn i løpet av uken for å se omfanget av skadene og gi en litt grundigere gjennomgang av hva dette nye nettstedet har blitt til og hvorfor det kan ha kostet 28 millioner kroner. Vel, det med pengene blir vel uansett et mysterium, men vi skal iallfall gi en gjennomgang!

PS! OG siden vi snakker om politiet så kanskje jeg bør legge til at mitt syn er kanskje ikke i overenstemmelse med min arbeidsgiver og at mine meninger er mine egne (selv om jeg føler meg på relativt trygg grunn her)

I artikkelen hevdes det at nå tar det snart av for emnekart og grunnen er at følgende nettsteder har vunnet priser i det siste (alle er emnekartnettsteder): regjeringen.no, stortinget.no, skatteetaten.no og nå også visitnorway.com. Grunnen til at emnekart er så fint er blant annet at:

- Det helt nødvendig å kaste den mentale forestillingen om webtjenesten som et hierarki der forsiden er eneste inngang. I stedet må det dyrkes frem tydelige seksjonssider og navigasjons- og knutepunkter som kan bli tjenestens nye innganger, forklarer Jørgensen.

Dette kan jeg like. Det er bra at man innser at forsiden ikke er den viktigste siden på nettstedet (for alle)! Seksjoner nettstedet, strukturer det i mindre områder slik at det er lettere å få oversikt for brukeren. MEN jeg synes at emnekartnettsteder mangler det menneskelige aspektet som gjør at man redaksjonelt/manuelt vurderer noe som relevant evt. irrelevant til den artikkelen man leser. Den mennesklige vurderingen av relevanse ville kunne redusere mengden av (irrelevante eller svakt relevante) linker som knyttes til enhver artikkel.

For å bruke artikkelforfatterens egne ord: det blir rett og slett for mange navigasjons- og knutepunkter til enhver side i nettstedet. Er det emnekartteknologien som gjør at det blir slik eller er det bare designerne/informasjonsprodusentene som har en hang til å inkludere for mye som “relatert” info?

Jeg er derfor uenig i at emnekart er løsningen. Emnekart fjerner hierarkiet, men den mentale forestillingen om hierarki blir ikke erstattet med en tydelig mental modell som fungerer bedre for brukeren.

Jeg leste også kommentarene til artikkelen og det siste innlegget var av Are Gulbrandsen hvor han trekker frem visitnorway.com som har vunnet en pris. Ok, jeg har sett de andre nettstedene så jeg går inn på visitnorway for å se om jeg blir positivt overrasket over enkel og genial struktur og oversikt. Jeg brukte ikke lang tid på å finne et grovt eksempel på at relatert informasjon til selv sentrale sider fremstår som helt irrelevante og har relaterte artikler på forskjellig logiske nivå.

Scenario: Tenk deg at du er interessert i få vite om bilferie i norge. Du finner en side som heter “Driving in Norway” på de engelske sidene.

Veien dit er ikke intuitiv. Denne ligger under hovedkategorien “Where to go” (men ikke under hovedkategorien “What to do”…??). Man klikker på “Where to go” i toppmenyen. Da kommer man til en hovedside med et vell av alternativer på høyre side… greit nok… velger “Driving in norway” og får denne artikkelen. Dette må være et slikt knutepunkt som man nevner i digi.no artikkelen…?

Det er flere problemer med denne knutepunktsiden (som jeg mener er  noe som er gjennomgående fenomen på emnekartnettsteder generelt). Nå kan man ikke se at man har kommet hit via “Where to go” – det er faktisk helt umulig å se hvordan man har kommet til denne siden hvis man skulle ha dumpet hit via et søk i Google eller andre søkemotorer. Dette bryter mot helt elementære navigasjonsprinsipper om at man skal vite hvor man er, hvor man har vært (og hvor man kan gå).

Dette betyr at jeg som nyankommen besøkende ikke har mulighet til å prøve å danne meg et mentalt bilde av hvordan dette nettstedet er strukturert fordi jeg får ingen clues om hvor jeg er eller hvor jeg “har vært”.

Hvis du også ser hvilke artikler som er relaterte til dette store temaet “Driving in norway” så får man to linker: “The atlantic road” og…. “Getting to Rauland”… Rauland?? Hva er det?? Hvorfor skal jeg dit? Hvordan kan et såpass spesifikt og uinterresant treff havne som relatert informasjon til den generiske siden “Driving in norway”?

Når relatert informasjon dukker opp i høyrekolonne på denne måten som er helt irrelevant (og på et annet logisk nivå) så skylder jeg på emnekart. Kanskje ikke teknologien per se, men at innholdsprodusentene må ha tunga relativt rett i munnen for å få sving på sider som dette. Når man tagger enkeltartikler man skriver og dette dukker opp helt ukritisk basert på at teknologien får et match på emneord så blir det som regel dårlig kommunikasjon. Jeg tror rett og slett det er så vanskelig å lage emneordlistene og metaordene slik at det er tilnærmet umulig for en innholdsprodusent å treffe spikeren på hodet når han velger hvilke emneord som skal knyttes til artiklene.

Pris eller ikke pris – dette er ikke bra struktur og det kan se ut som om emnekart IKKE er god web-design allikevel!!

Omtalte sider:
Artikkel på digi.no:  http://www.digi.no/808475/god-web-design-er-emnekart

Driving in Norway på Visitnorway.com:  http://www.visitnorway.com/en/Articles/Theme/Getting-here-and-around/Driving-in-Norway/

Creunas blogg: http://blog.creuna.no/?p=175

Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case.

Jeg leste nettopp en artikkel som jeg synes var veldig bra i forhold til problemet som Douglas Bowman hadde. Les Bowman vs Google? Why Data and Design Need Each Other. I konklusjonen på denne artikkelen sier Tom Chi:

The interplay of all disciplines (engineering, design, research, marketing, sales, QA, product, legal, customer care, etc) is where the magic happens. Metrics are an absolutely critical interface between disciplines, but when wielded and controlled by only one discipline they can greatly limit the potential of the others. Doug’s goodbye letter paints a picture of exactly this type of dysfunction. A company that empowers only engineers will primarily produce engineering innovation — a company where all disciplines are represented can innovate in several spheres at once.

Noen ganger oppstår det slike konflikter mellom utviklere og designerne og (bruker)testing brukt for å trekke brukerne inn som dommere i kampen. Ofte for å kåre en slags vinner. Hvis vi tenker litt over innholdet i artiklene jeg refererte til ovenfor, kan det hende at vi alle taper på en slik innstilling?

Jeg har ansvaret for brukertesting i Tarantell og ønsker å teste mye og ofte, men dette viser at det er veldig viktig at man velger riktig verktøy / brukertestmetode for å få de svarene man trenger.  Jeg vil prøve å skrive litt om det i mitt neste blogginnlegg. Stay tuned som det heter

(PS! Jeg twitrer under brukernavnet haakonha – vi twitres!)

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.

Dette må være obligatorisk lesing for alle som bidrar til utvikling av programvare – enten man er produkteier, kunde, bruker, kravstiller, leder, interaksjonsdesigner, systemarkitekt, programmerer eller tester. Og for en gangs skyld er jeg ganske overbevist om at alle kan enes om en felles referanseramme. Istedet for å starte en ny debatt om hva som er det ene, korrekte svaret.

Nyt bildene, nyt innsikten – dette er nesten magisk:

http://www.cooper.com/journal/agile2008/

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).

Det finnes naturlig nok mye faglitteratur på temaet og trender kommer og går mht. hva som er “riktig”. De fleste har kanskje hørt om regelen som sier at man ikke skal ha mer enn 7 +-2 menypunkter? Opprinnelsen til denne regelen er fra en artikkel publisert i 1956 av George A. Miller som var en undersøkelse av korttidshukommelsen til ungdommer (se også en kort forklaring av teorien på Wikipedia). Jeg var senest på et U11 seminar i Boston i fjor hvor Gerry McGovern gjentok denne regelen og mente at den fremdeles gjelder for navigasjon. Det er bare en liten hake ved hele greia, man trenger aldri å huske/memorere en navigasjonsmeny – man skal bare kunne vite sånn cirka hvordan nettstedet er organisert og så scanne seg frem til riktig menypunkt! Derfor er det meningsløst å ha en regel som går på at man må begrense menyer til antall menypunkter som folk antas å kunne memorere selv. Lengden på hovedmenyen er stort sett aldri et problem i seg selv, men hvis du bryter en av mine sju regler for god menystruktur så vil du oppleve at brukerne dine får problemer. Garantert!

OK. Nok prat. Her er mine 7 regler for god menystruktur og navigasjon:

1. Lag et navigasjonskonsept som er lett å forstå for brukerne!
2. Finn en god balanse mellom bredde og dybde!
3. Menypunktene skal være på samme logiske nivå!
4. Det skal ikke være vanskelig for brukeren å velge menypunkt på toppnivå!
5. Ikke bruk fagutrykk i hovednavigasjonen!
6. Baser navigasjonen på nettstedet på ett hovedprinsipp for navigasjon, men tilby flere innganger til samme informasjon!
7. Vær konsistent!

Jeg vil gjerne ha kommentarer på disse reglene og hvis det er noe jeg har glemt så vil jeg gjerne vite om det også

Jeg vil prøve å uttdype disse reglene en etter en i blogginnlegg her på blogandtell.no og linke disse opp til denne artikkelen.

1. Installer Google Webmaster Tools http://www.google.com/webmasters
   • Dette verktøyet kan hjelpe til med å få kontroll på hva som blir indeksert av de store søkemotorene. Les mer på http://www.sitemaps.org.
   • Google Webmaster Tools krever at man legger ut en XML fil på nettstedet på samme format som dette eksempelet. Vær imidlertid oppmerksom på at når sitemapen legges ut må strukturen på nettstedet allerede være optimalisert. Finnes det indekseringsproblemer vil sitemapen ikke forbedre dine posisjoner eller ordne interne problemer. Sitemapen vil kun sørge for at søkemotorene plukker opp nytt innhold fortere. Man vil heller ikke ha mulighet til å avdekke indekseringsproblemer når man leverer alt på et sølvfat til søkemotorene.
   • Det finnes flere forskjellige løsninger som kan hjelpe deg å få dette opp. Jeg benytter meg av en tjeneste fra http://www.iarchitect.net/
2. Ha en robots.txt på ditt nettsted.
   • Denne vil hjelpe deg til å kun få indeksert det du ønsker å ha indeksert. Og vil også gi deg mulighet til å fjerne evt ”duplicate content”.
   • Et eksempel på robots.txt kan du finne her.
   • Som dere kan se i eksempelet så har jeg her lagt inn et Wildcard: ”Disallow: /*?YearMonth=* som gjør at kalenderfunksjonen på bloggen min ikke blir indeksert. Før jeg la til denne funksjonen i robots.txt var denne URL’en en spider trap.
3. Installer et logganalyseverktøy på dine sider
   • Logganalyse vil kunne vise deg effekten av optimalisering og andre forbedringer.
   • Det finnes mange forskjellig analyseverktøy, og hva du trenger bør baseres på kost/nytte, personlig liker jeg Webtrends eller Xtractor
     
   • Opp til en viss mengde sidevisninger er verktøyet Google Analytics gratis.
4. Siden din skal validere etter W3C standarden
   • Det finnes flere verktøy du kan benytte. En enkel test kan du gjøre via validatoren til W3C
5. Jobb med inngående linker til ditt nettsted
   • En fint verktøy til å analysere inngående linker er Back Link Analyser.
   • Skaff deg relevante linker fra populære kataloger som http://www.dmoz.org , http://www.startsiden.no og andre aktuelle nettsteder
   • Kjøp deg plass i viktige kataloger, men pass på å tenk kost/nytte. Du kan med god logganalyse optimalisere markedsbudsjettet ditt på en fornuftig måte. Vi nettstedseiere bruker alt for mye penger på katalogoppføringer som ikke gir noe tilbake.
6. Pass på at du ikke har ”duplicate content” på forskjellige domener.
   • Har man for eksempel to domener som går til samme innhold, og dette ikke er satt opp riktig, så vil Google velge ut en av dem. Primærdomenet ditt skal være satt opp på vanlig måte. Mens ditt sekundære domene skal peke med en 301 redirect til primærdomenet.
7. Domenestrategi og språk
   • Hvis markedet ditt er Norge så blir .no domener prioritert i resultatet på norske søk.
   • Det er stor forskjell på språk. Mange tenker ikke på språkforskjellen når de for eksempel skal lage sider for det amerikanske markedet. Det er stor forskjell på Britisk kontra Amerikansk.
8. Ikke forsøk å manipulere deg til gode plasseringer i de store søkemotorene
   • Jeg pleier å spørre meg selv om optimaliseringer jeg gjør kommer brukerne tilgode eller har de som mål å skaffe høyere plasseringer i søkemotorene. Jeg stiller meg tvilsom til endringer som ene og alene handler om plassering i søkemotorene.
   • Det finnes mange tilfeller der nettsider har blitt kastet ut av Google på grunn av bruk av gråsonemetoder eller rene juksemetoder
     • Bolia ble kastet ut av Google ved bruk av gråsone metoder
     • Radisson Sas ble kastet ut av google ved bruk av juksemetoder
     • Prioritet.no kastet ut av Google
     • Vær VELDIG forsiktig med bruk av ”Content Rich Doorways”
9. Optimalisering av malverk
   • Differensier Title tag’en på hver side.
   • Overskriften på for eksempel en artikkel burde være tagget med en H1.
   • Title og overskrift burde være identiske.
   • Det må være differensiert Meta Description på hver side.
   • Man burde være flink med å skrive interne lenketekster.
10. All navigasjon burde ha en alternativ navigasjonsform
    • Ved bruk av navigasjon i Image Maps, burde du legge til rene tekstlinker under.
    • Ved bruk av Javascriptnavigasjon burde du legge til en sitemap (nettstedskart), godt synlig for brukeren, som gjør at brukere som ikke har støtte for Javascript kan navigere. Sørg for god nedbrytningsvennlighet.
    • Flash kan fint brukes på dine sider, men husk at informasjon eller linker i flash ikke blir veldig godt mottatt av de store søkemotorene
    • Ikke bruk noen form for redirects i navigasjonen din. For eksempel så liker ikke de store søkemotorene 302 redirects
    • Url’ene dine burde være ”snille”. Her kan man for eksempel benytte seg av ISAPI filteret for IIS eller HTACCESS for Apache. Mange gode publiseringsløsninger har god støtte for dette
11. Innhold.
    • Lag innhold som brukeren er ute etter. Styr unna fagspråk.For eksempel så heter det IKKE ”synshjelpemidler”, men ”linser” eller ”briller”.
    • Bli en autoritet innholdsmessig.
    • Bruk viktige nøkkelord i viktige innholdselementer som TITLE TAG og overskrifter.
    • Jeg kan anbefale innholdskurs fra http://www.nettredaktor.no

Det er mengder av andre ting man kan gjøre for å bedre sin digitale synlighet, men benytter du deg av disse tipsene så er du på god vei. Mye kan gjøres med sunn fornuft, god programmering og en god publiseringsløsning med en bra kravspesifikasjon. Bli en autoritet på ditt fagfelt innenfor din bransje. Tenk mer på å gjøre det riktige i forhold til brukeren din enn å ha fokus på plasseringer og Page Rank. Det er ikke noe poeng å få 1 million nye brukere fra søkemotorer hvis du ikke kan håndtere dem og konvertere dem til butikk.

Det finnes helt klart gode aktører der ute som kan hjelpe deg. Men vær forsiktig med hvem du velger. Det er ikke uten grunn at SEO bransjen ofte omtales som en cowboy bransje. Hold deg så godt oppdatert som mulig. Søkemotorene forandrer seg hele tiden, det som var viktig i går er kanskje ikke viktig i dag.

En siste ting som helt klart burde adresseres er når du skal bytte løsning eller endre informasjonsarkitekturen. Husk å ta vare på gammel morro, eller eventuellt rydde opp i gammel morro.

Gode kilder for SEO

http://www.google.com/webmasters

http://www.searchenignewatch.com

http://seospamcops.wordpress.com


Har du spørsmål vedrørende fagfeltet. Ikke nøl med å skrive en e-post til meg: roar@tarantell.no

Avslutningsvis så vil jeg bare si en ting. Make it good for the user, and Google will love you

Så langt har jeg benyttet følgende:

• Powerpoint
• Visio
• Word
• Dreamweaver
• Illustrator
• Axure
• Papir-skisser

Andre kollegaer har også jobbet med:

• Pdf prototype
• Photoshop
• Flash

Alle disse ulike variantene har styrker og svakheter, men for å komme med konklusjonen først: Axure Pro (4.6) er pr. i dag det beste verktøyet for å prototype nettløsninger i min mening.

Axure Pro

Fordelene er at man kan lage forholdsvis interaktive prototyper uten å måtte være en racer på verken design eller html. Det er som å tegne i photoshop eller illustrator med den fordelen at man i større grad kan lage “masters” (maler) eller “widgets” (kompnenter) som man kan gjenbruke hvor man vil og så ofte man vil på alle sider. Hvis man endrer på en widget eller en master så vil endringen gjenspeiles på alle sidene denne er brukt. Man kan også flette flere masters sammen til å danne en ny master. Dette gjør at man bygger opp ett sett av byggeklosser (”moduler”) som man kan benytte en eller flere ganger i prototypen. Når jeg ønsker å teste ut et flyt så kan jeg eksportere sidene til en interaktiv html prototype og klikke meg rundt i løsningen.

Prototypen kan være nær opp til den relle løsningen eller kun som kjedelige trådskisser uten design. Begge deler er det mulig å lage med Axure. Men så fort man trekker inn designet så blir det selvfølgelig mer å tenke på og det er lett for at man blir sittende i timesvis å fikse på småting for at det skal se bra ut.

Eksempel på en trådskisse (med klikkbart nettkart til venstre):

Et eksempel på en “low fidelity” prototype av forsiden til Aschehoug.no.

Når vi hadde jobbet en stund med innhold, struktur og design så lagde vi en klikkbar prototype som kunne brukertestes. Denne så slik ut:

Et eksempel på en “high fidelity” prototype av forsiden til Aschehoug.no. Alle linker og bilder er klikkbare og fører til innhold, selv om ikke all tekst er riktig.

OK, flott! Tenker du – da er det jo bare å rulle ut og vi sparer penger på å utvikle frontend og html – dette ser jo flott ut! Ja, det ser flott ut, men koden er søppel! Dette er gjort med hensikt. Axure er et flott verktøy til å prototype og det betyr at når prototypen er ferdig så må jobben med å etablere teknisk rammeverk og visningsrammeverk gjøres fra bunnen av, men man har et godt utgangspunkt som er litt mer matnyttig (?) enn å lese en tørr dokumentasjon laget i word eller visio. OG man kan fint brukerteste prototypen for å få vekk en del feil før man setter i gang. Jeg synes det er god ting at jeg slipper å måtte kvalitetssikre html kode eller annet for å kunne sette opp en prototype raskt og uten å tenke på gjenbruk. Jeg har brukt Dreamweaver før, men det som skjer er at hvis man lager noe interaktivt ved å bruke predefinerte funksjoner (klipp og lim) så lager det såpass mye dårlig kode at front-end utvikleren river seg i håret i frustrasjon og må som regel begynne på nytt allikevel.

En siste fordel med Axure er at størrelsen på nettstedet (antall sider) gjør det ikke så veldig mer komplisert. Jeg har laget prototyper med hundre sider og med ti sider, begge deler fungerer fint. Hvis man prøver å lage en 100 siders protoype med powerpoint så har man garantert en kjempejobb med å kvalitetssikre lenker før en eventuell brukertest.

Jeg har imidlertid lyst til å høre hva du mener er et godt verktøy for prototyping. Men la meg slippe å høre “jeg koder alt i notepad” varianten – alle vet at det tar lengre tid