Gode grensesnitt: Siste punkter om webstandarder
Gjennom fire innlegg for to uker siden utformet jeg et forslag til krav til god grensesnittsimplementasjon i kategorien webstandarder. Et innlegg til hører med før vi går videre: idag handler det om tegnsett, RSS, nettleserstøtte og mer.
Bakgrunn: Sjekkliste for grensesnittsutvikling.
Tegnsett
Bruk riktig tegnsett på alt innhold. For norskt innhold bør UTF-8-enkoding foretrekkes for å være sikker på at alle spesialtegn og særnorske tegn vises riktig. Det bør om mulig benyttes samme tegnsett i alle lag i applikasjonen (database, CMS, grensesnitt, eksterne tjenester, andre lag) for å minimere sjansene for feil knyttet til dette.
Til sluttbrukeren kan tegnsett spesifiseres med Content-Type-headeren, og bekreftes med den tilsvarende meta-taggen.
Hvorfor?
- Sikre riktig visning av spesialtegn og språkspesifikke tegn
Hvordan?
- Sett riktig tegnsett gjennom HTTP-headeren Content-Type
- Bekreft tegnsett i tilsvarende meta-tag. Fordelen med dette er at sider også vil vises riktig om brukeren skulle finne på å laste ned sidene og kjøre de lokalt fra sin maskin.
- Bruk om mulig samme tegnsett i alle lag i applikasjonen (fra database/tjeneste til klient) for å minimere antall feilkilder
RSS/Nyhetsstrømmer
Ethvert nettsted med innhold av interesse burde tilby en RSS-feed slik at brukerne har mulighet til å abonnere på innholdet ditt på den måten de selv ønsker.
En RSS-feed kommer i mange varianter, med formater som Atom 1.0, RSS 2.0, 1.0, og 0.9x. I følge John Panzers RSS best practices bør du foretrekke å støtte Atom 1.0, med RSS 2.0 som andrevalg.
Atom er ikke egentlig RSS - det er to (egentlig flere) forskjellige formater - men RSS brukes ofte som et samlebegrep for nyhetsstrømmer. Atom 1.0 er designet for å ta over for RSS etter at RSS har havnet i et salig sammensurium av inkompatible versjoner. Selvom mange større selskaper (som for eksempel Google) har omfavnet Atom er RSS fortsatt utstrakt i bruk, da spesielt RSS 2.0 for podcastere.
Akkurat som med andre standarder er det en hel rekke verktøy tilgjengelig for RSS/Atom, så som W3Cs feed validator. Det er like viktig å sørge for at nyhetsstrømmen er ved sin beste helse som å passe på at resten av nettstedet holder teknisk mål.
Valider etter publiserte standarder for feeds
Uavhengig av valgt(e) format(er), bruk valideringstjenester til å validere strømmen. Foretrekk Atom 1.0, med RSS 2.0 på andrevalg. Se forøvrig en sammenligning av de to formatene.
Hvorfor?
- Validerende nyhetsstrømmer er nødvendig for å sikre at strømmen fungerer i alle RSS-lesere
- Atom 1.0 og RSS 2.0 er de to best støttede formatene
Hvordan?
- W3Cs feed validator
- Feedvalidator en annen valideringstjeneste
Tilrettelegg for autodiscovery
Autodiscovery av nyhetsstrømmer tillater nettlesere og andre tjenester å finne RSS- og ATOM-feeds bare ved hjelp av URL-en til et nettsted. Dette letter abonnering for sluttbrukeren.
Hvorfor?
- Nettlesere og andre tjenester finner RSS- og ATOM-feed bare med hjelp fra URL-en til nettstedet
- Lettere for sluttbrukere å abonnere på nyhetsstrømmer
Hvordan?
- Legg til
link-elementer som lenker opp strømmene dine - Bruk
link-elementene på alle sidene i løsningen - Bruk riktig
Content-Type(application/rss+xml,application/atom+xml) - Angi
Content-Typemed små bokstaver
link-elementene det her er snakk om er
<link rel="alternate" type="application/atom+xml" title="ATOM feed" href="/feed/atom" />
<link rel="alternate" type="application/rss+xml" title="RSS feed" href="/feed/rss" />Andre gode RSS/ATOM-tips
- Spre feeden din gjennom Feedburner - Ved å distribuere feeden gjennom Feeburner åpner du for statistikk på feed, mulighet for eksponering gjennom deres nettverk og mer
- RSS/Atom feeds: best practices
Nettleser-støtte
De dyktige menneskene på Yahoo! har gjort mye bra for grensesnittsteknologien (la oss håpe at de fortsetter med å ikke være eiet av Microsoft...), og en av disse tingene er deres Graded browser support.
Gradert nettleserstøtte gir en mer nyansert definisjon av støtter enn "støtter" og "støtter ikke". Grunnprinsippet går ut på at man prioriterer innholdet, og legger til ekstra funksjonalitet så som script og fancy design på en måte som fungerer for de som har støtte for det, men som ikke ødelegger for de med eldre utstyr osv. Dette prinsippet er også kjent som progressiv forbedring (" progressive enhancement").
Med gradert nettleserstøtte kan man si noe om i hvilken grad en nettleser støttes. Nettlesere vurderes ut i fra hvor gamle de er, hvor godt de implementerer webstandarder, hvor mange som bruker dem og andre kriterier. Med denne dataen lager man seg en matrise over nettlesere og operativsystemer og på hvilken måte de skal støttes. Skal all funksjonalitet fungere perfekt? Er det nok at innholdet kommer igjennom?
Flere detaljer rundt dette finnes hos Yahoo! Nå er det ikke gitt at alle trenger å støtte de samme klientene som Yahoo! gjør, men det kan være et godt utgangspunkt. Et annet utgangspunkt kan være ditt eget publikum (bruk statistikk aktivt).
Bruk progressiv forbedring
Hvorfor?
Som forklart over så er poenget med progressiv forbedring å sette innhold i hovedsete, og deretter legge til ekstrafunksjonalitet. Det er viktig å merke seg at dette ikke er det samme som "grasiøs degradering" (" graceful degradation), som prioriterer i motsatt rekkefølge, selvom meningen er lik.
Hvordan?
- Utvikle med innhold i fokus
- Utvikle fallbackløsninger før du legger inn JavaScript
- Skill CSS og JavaScript ut i eksterne filer
Jeg har tidligere skrevet om ikke-påtrengende JavaScript, som er et viktig konsept for progressiv forbedring.
Definer støttede klienter og test for dem
For ethvert prosjekt bør det på forhånd gjøres en aktivt innsats på hvilke klienter som skal støttes på hvilken måte. Yahoo!s nettleserkart er et naturlig utgangspunkt her, men som tidligere nevnt bør man ta sine egne behov og besøkende i hensyn også.
Én ting man skal passe seg for når det gjelder å bruke statistikk i denne prosessen er å bruke la statistikken bli en selvoppfyllende profeti. Hvis du ikke har noen Safari-besøkende i det hele tatt på nåværende tidspunkt - kan det kanskje komme av at Safari-brukere ikke er i stand til å bruke nettstedet (og ikke at de ikke er interessert)? La heller ikke egne meninger og blind tro på dagens situasjon plassere moderne nettlesere i "C grade"-boksen.
CSS til utskrift
Ved hjelp av media-typer er det mulig å gi forskjellig CSS til forskjellig bruk. Benytt dette til å lage nettdokumenter som printer godt. La utskriften være en aktiv del av utviklingen, og se til at dokumenter som skrives ut er lette å lese, at de ikke inneholder unødige forstyrrende elementer (så som navigasjon, skjema osv) og at de passer inn på vanlige ark.
Andre gode tips
I en samlekategori som dette er det nok plass til et utall småtips, har du flere essensielle tips enn de som er gitt her vil jeg gjerne høre om dem!
