Hopp til innhold

Visjon

Jøkul er vår kollektive læring, dokumentert og satt i system. Designsystemet gir oss felles normer for hvordan vi bygger digitale produkter og tjenester.

Hovedprinsippene

Å designe og programmere for web betyr blant annet å ta høyde for at siden din kan bli vist på alle mulige skjermbredder. Det holder ikke å bare ta høyde for at et design fungerer på en mobil, en tablet, og en desktop i fullskjerm – det må også fungere på breddene mellom disse størrelsene.

For Designere

I praksis betyr det for deg som designer å bruke Auto layout og se hvordan designet ditt tåler å bli skvist sammen og strukket ut. Blir det så trangt at teksten er vanskelig å lese, eller ser det rart ut når en komponent blir veldig bred? Da må du enten justere designet litt på den skjermstørrelsen, eller tenke helt nytt.

Ofte er det små justeringer som trengs – kanskje bare at vi bytter til "neste" layout litt tidligere for akkurat den delen av siden. Alliér deg gjerne med en utvikler om du trenger noen å sparre med.

For Utviklere

Som utvikler betyr det at du må være forberedt på å teste det du programmerer på ulike skjermstørrelser. Det kan være så enkelt som at du drar nettleservinduet så det krymper og vokser mellom en liten og stor bredde. Test gjerne også med zoomfunksjonen i nettleseren. Ved å zoome ut kan du få inntrykk av hvordan siden ser ut på skjermer med høyere oppløsning enn din egen.

Se etter layoutproblemer. Om du finner noen, snakk med designer, og kom gjerne med løsningsforslag. Avhengig av løsningen kan det hende du må kode inn et eget media query som løser ditt spesifike problem på skjermbredden det gjelder.

Brekkpunkter

Dette er verdiene vi bruker innad i Jøkul. Det vil si at typografi og spacing i komponenter vil forandre seg ved disse breakpointene.

Du står fritt til å lage egne breakpoints

Du kan fortsatt bruke akkurat de breakpointene du trenger i din egen app, sånn at layouten din fungerer godt på alle skjermstørrelser.

Oppfører en komponent seg rart?

Om du synes en komponent fungerer dårlig på en viss skjermstørrelse er det supert om du sier i fra. Sett i gang en diskusjon, gjerne med skjermbilder og hvilke skjermstørrelser det gjelder.

Mobil først?

Det kommer an på. Et internsystem for et fåtall superbrukere har ikke de samme forutsetningene og behovene som en side privatkundene våre møter når de er på farten. Du kjenner best dine brukere, deres behov, når og hvordan de bruker løsningen din.

Hvis målgruppen er privatkunder skal vi typisk alltid ha en godt fungerende løsning på mobil. Da kan det være verdifult å starte designet på den flaten som kan være mest utfordrende. Det er ofte lettere å legge til ting enn å trekke dem fra.

Om det du designer er et arbeidsverktøy som ni av ti ganger brukes fullskjerm på en desktop gir det ikke nødvendigvis mening å starte på små flater. Det er verdt å huske på at, selv om brukeren i teorien kan bruke hele skjermen, er det ikke gitt at vi har hele skjermen som boltreplass, selv på desktop. Hvor ofte sitter du for eksempel med en 50/50 splitt på din egen skjerm? Det er derfor fint at løsningen i det minste kan brukes på mindre flater.

Kjenn brukerne

Teamet ditt har kanskje statistikk på blant annet vanlige skjermstørrelser hos brukerne deres? GlobalStats har noe statistikk, men den kan være av variabel kvalitet. Foretrekk å bruke egen statistikk fra løsningen deres, eller å hente statistikk fra liknende løsninger i Fremtind. Kontakt Jøkul-teamet eller spør på Support Designsystem om du har spørsmål.

Viktig å huske

Det er mange bevegelige deler man må tenke på når man designer responsive løsninger. Gi interaktive elementer god plass, tilpass tabeller til mindre skjermer, bruk høyere punkttetthet for bilder på skjermer med høy oppløsning, og bruk SVG-format for vektorgrafikk.

Størrelse er viktig for tilgjengelighet

Det er viktig å ha god nok plass på interaktive elementer, som knapper. Apple anbefaler minimum 44 ganger 44 pixler som touch target.

Responsive tabeller

Tabeller er blant de vanskeligste å ha på mobilstørrelser. Det er flere måter å løse dette problemet på, inkludert å la tabellen falle ned til en liste i mobilvisning, spesielt hvis du har store kompliserte langbord med mye data. Se Table for noen eksempler.

Responsive bilder

Skjermer med høy oppløsning, som Retina-skjermer, kan trenge bilder med høyere punkttetthet enn 72 dpi for å se bra ut. Det er viktig å huske på at et bilde med høy oppløsning og punkttetthet har en betydelig datamengde og gir en dårlig opplevelse på mobil, som kan ha en begrenset båndbredde. Det er flere måter å løse dette på, avhengig av verktøyene som brukes i teamet. Noen verktøy kan ta et høyoppløst bilde og lage responsive bilder for ulike skjermstørrelser og punkttetthet. Andre ganger må vi lage disse bildene selv, og sørge for at rett bilde brukes på rett skjerm. Se Image for et mulig hjelpeverktøy for utviklere. Generelt sett skal alt som kan være vektorgrafikk være i SVG-format og ikke som et bilde.

Lenker

Dette temaet er for stort til å dekke på bare en side. Vi anbefaler alle å lese seg opp på nyere informasjon regelmessig. Ta en kikk på lenkene nedenfor som et utgangspunkt. Still spørsmål og vær nysgjerrig.