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

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)

www.webeloquence.co.uk

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