Retningslinjer for eget design og egen funksjonalitet (CSS, Javascript) i UiOs Canvas

Det er stort engasjement fra noen av fakultetene angående design og funksjonalitet i Canvas, og enkelte fakulteter har ressurser og utviklere med kompetanse på CSS/Javascript og et ønske om å utvikle egne design og merfunksjonalitet for noen av sine Canvasrom. Eksempler er HELP v/ MED og HF:Studio.

Det er mulig også for andre enheter å være med, men det må skje i samråd med systemeier for Canvas (DIG) og fakultetskoordinator, og alle må følge retningslinjene.

Hvorfor?

I utgangspunktet ønsker systemeier for Canvas ved UiO at designet og funksjonaliteten skal være mest mulig likt for brukere på tvers av emner og fakulteter ved UiO, særlig for ordinære studier, men ser behovet for lokale varianter og behov som ikke dekkes av rammeverket. Derfor er det åpnet for at enheter med kompetanse til å utvikle design/funksjonalitet for noen eller alle av sine Canvasrom.

Hva betyr "eget design" og "egen funksjonalitet"?

Eget design/egen funksjonalitet i denne sammenhengen betyr innad i et Canvasrom som man får til med CSS og Javascript. Det kan være endringer til både utseende (f.eks. fargetemaet) og til funksjonalitet (f.eks. inline quiz). Se lenger ned for hva som kan og ikke kan endres innad i et Canvasrom.

For enkelthetsskyld, "designet" i denne veiledningen omfatter både design og funksjonalitet.

Om noe blir utviklet som kommer til gunst for alle brukere og alle rom, kan systemeieren bestemme at det blir en del av rammeverket i Canvas og tilgjengelig for alle.

Før utvikling begynner

  • Fakultetskoordinator tar kontakt med systemeier for Canvas med informasjon om planene. Det blir kalt inn til møte ved behov.
  • En del av betingelsene for å få lov til å utvikle eget design er at enheten/fakultetet som utvikler designet må være i stand til å drifte det og rette feil som oppstår. Systemeier for Canvas kan ikke påta seg denne oppgaven.
  • Systemeier må godkjenne planene for eget design i UiOs instans. Hvilke vurderinger tas?
  • For nye enheter som vil utvikle: Etter godkjenning ordner Canvas-systemeier brukertilganger, en egen utviklingsunderkonto i Canvas til bruk for utvikling og testing, og tilgang til Teams slik at utviklerne og systemeier holder kontakt underveis.

Utvikling

  • Utvikling foregår i utviklingsunderkontoen som Canvas-systemeier har opprettet. Der laster utviklerne opp CSS- og Javascript-filer i Temaeditor fra admingrensesnittet (instructure.com).
  • Utviklerne kan opprette Canvasrom på denne underkontoen, eller flytte rom med innhold dit. 
  • Testing av designet gjøres med utviklernes egne brukere og med studentvisning i Canvas. Hvis det er behov for testing med ekte studentbrukere, skjer dette i samråd med systemeier.
  • Det skal ikke flyttes ekte rom med studenter/deltakere til utviklingsunderkontoen for å bruke eller teste designet uten at det skjer i samråd med systemeier.
  • Det er viktig å teste både nettleser og mobilapp.
  • Designet/funksjonaliteten må møte krav til universell utforming og personvern.
  • Javascript som lages skal ikke sende data om brukerne ut av Canvas

Samarbeid på tvers

  • Enheten som utvikler designet/funksjonaliteten oppfordres til å holde andre orientert om planene i Teams og må gjerne samarbeide med andre enheter. Det kan være at andre har gjort eller ønsker å gjøre det samme.
  • Systemeier for Canvas har jevnlig dialog med andre Canvas-systemeiere i norsk UH-sektor og kan eventuelt ta kontakt for å se om andre har utviklet lignende løsninger i Canvas.

Hva kan - og ikke kan - endres med eget design?

I dette bildet har vi delt opp Canvasrom i ulike soner:

Skjermbilde av et Canvasrom, med hele grensesnittet delt opp i fem soner

Se bildet i fullstørrelse

Ikke kan endres/gjøres

Designrammeverket som er satt av systemeier på Canvas inneholder blant annet font/fontstørrelser på tekst og overskrifter, grunnfarger i navigasjonsmenyen, lenker, knapper, tekst og grafiske elementer, i tillegg til UiO-logo og -segl. 

🚫Verken navigasjonsmenyen (sone 1 i bildet), rommenyen (sone 2 i bildet) eller UiO-logo og -segl kan endres/fjernes med eget design - UiOs Canvas må være gjenkjennbar.

🚫Javascript som lages skal ikke sende data om brukerne ut av Canvas.

Kan endres/gjøres unntaksvis

⚠️Farger på lenker, knapper, tekst og grafiske elementer, og font/fontstørrelse på tekst og overskrifter i rammeverket kan unntaksvis endres hvis det er tungtveiende grunner og enheten har ressurser til å drifte og vedlikeholde et mer omfattende design. Eksempler er MOOC som flyttes til Canvas, eller større e-læringsressurser/-kurs som avviker fra ordinære studier.

⚠️Andre deler av Canvas, som for eksempel dashbordet, brukerinnstillinger, admingrensesnittet, kalender, innboks, osv., kan ikke endres uten samråd med systemeier for Canvas.

Kan fritt endres/gjøres

👍Fargetemaet og funksjonalitet i body (sone 3) kan fritt endres.

👍Noen ønsker at header (sone 4) i et sett Canvasrom får et eget bakgrunnsbilde. Dette kan gjøres, men grunnfunksjonaliteten i headeren (hamburgermenyen og knappene) må fremdeles være tilgjengelig og godt synlig for brukere.

👍Høyremargen (sone 5) på forsider og sider kan også endres, men grunnfunksjonaliteten (knapper i forsiden) må fremdeles være tilgjengelig og godt synlig for brukere.

Implementering, drift og vedlikehold

  • Før noe kan implementeres må enheten lage et "showroom" i Canvas som er åpent for andre, som både viser funksjonaliteten/designet som er lagd samt dokumenterer løsningen. Dette gjøres for å dele med andre fakulteter og for å ha et forutsigbart sted å finne dokumentasjonen.
  • Godkjenning og implementering av designet i ekte rom gjøres av systemeier for Canvas. Enheten tar kontakt med systemeier med lenke til "showroomet", og systemeier tester og vurderer designet/funksjonaliteten som er utviklet. 
    • Vurderinger som tas: personvern, universell utforming, om det er konsekvenser for studier/eksamen, potensielle sårbarheter med ønsket løsning, om systemeier skal løfte behovene til sektoren/leverandøren for å se om det finnes andre løsninger, m.m.
    • Behandlingstid: Hvis enheten holder en tett dialog med systemeier og andre fakulteter underveis vil det være mulig for systemeier å ta vurderinger fortløpende, og dermed redusere behandlingstiden når designet er ferdigutviklet.
  • Systemeier kan vurdere at deler av designet/funksjonaliteten som er utviklet er til gunst for andre og skal implementeres for flere fakulteter, eller i alle Canvasrom. 
  • Dersom designet/funksjonaliteten står i strid med retningslinjene eller lovkrav står systemeier for Canvas fritt til å fjerne eller avvise designet.
  • Når designet/funksjonaliteten er godkjent for bruk er det Canvas-systemeier som aktiverer det i underkontoer med ekte rom i Canvas.
  • Drift og feilretting: Det er enheten som har utviklet designet som har ansvar for å drifte og vedlikeholde det. Dersom ikke enheten er i stand til å rette feil som oppstår i eget design står systemeier for Canvas fritt til å fjerne designet.

 

Publisert 9. okt. 2026 10:35 - Sist endret 9. okt. 2026 10:35