En skrivbar web; fokus på innhold, tekniske forutsetninger og formater for deling og gjenbruk

Transkript

1 Back to basic: En skrivbar web; fokus på innhold, tekniske forutsetninger og formater for deling og gjenbruk Høgskolelektor Arnstein Gjestland, Høgskolen Stord/Haugesund Nettverksuniversitetet, mars 2004 Delrapport fra Fagforum for produksjonsteknikk

2 Innhold 1 Innledning Innhold, det er tekst det Skillet mellom struktur og utsende «Håndskrevet» html Navigasjonssystemet Hvor bør kompleksiteten ligge? En og bare én versjon Matematikk, webens «grimme elling» LAMP Standarder for e-læring Utviklingen innen e-læringssystemer Konklusjon...16 Høgskolelektor Arnstein Gjestland 2

3 1 Innledning Nå er det ca. ti år siden jeg produserte mine første websider. I det følgende vil jeg diskutere en del prinsipper og hjelpemidler for å skrive «fornuftige» web-dokumenter, dvs dokumenter som prøver å tilfredstille en av W3c sine merkings-standarder. I tillegg vil jeg presentere en prototyp som forsøker å illustrere noen av disse prinsippene og viser at man mha. «opensource» løsninger kan sy i sammen en skrivbar web. Avslutningsvis vil jeg kort diskutere noen av de e-lærings spesifikasjonene og standardene som nå begynner å gjøre seg gjeldene. 2 Innhold, det er tekst det En atoverveiende del av det jeg har behov for å presentere er tekst og eventuelt noen bilder. Svært mange av de ferdiglagede web-portalene ofrer imidlertid svært liten plass til selve innholdet, dvs teksten. Storparten av nettleser vinduet er fylt opp av logoer, navigeringssystem, søkesystem, kalender osv. Teksten er ofte tildelt et liten hjørne nede til høyre. For liksom å fylle den plassen som ble til overs. Alt dette medfører at lesbarheten ofte blir kraftig redusert. Hvis man i tillegg har et mindre heldig valg av bakgrunn og tekstfarge så kan det å få lest selve teksten være en utfordring. Når man blir nødt til å klippe ut teksten og lime den inn i en editor for å kunne få lest teksten så har «webdesign» gått for langt. Det er dermed et stort paradoks at de merker (eng: tags) som er nødvendige for å sette opp en ryddig og leservennlig tekst har vært tilgjengelige iallfall fra html 2.0. Benytter man de 6 nivåene for overskrifter (<h[1-6]>), de tre listene (<ul>, <ol> og <dl>), avsnitt (<p>) og preformatert tekst (<pre>) så har man langt på vei verktøyet for å skrive en godt strukturert tekst. En stor fordel ved å holde seg til de merkene som er tenkt å beskrive tekst, og ikke misbruker dem, er at teksten vil fungere bra i alle nettlesere. Teksten vil være lesbar selv i små vinduer uten å måtte benytte horisontal rulling («horizontal scrolling») som virkelig ødelegger lesbarheten. I tillegg vil man ha en godt strukturert tekst som er enkelt å bearbeide og f eks konvertere til andre formater og som i tillegg er et godt utgangspunkt for brukere med ulik grad av synshemning. 3 Skillet mellom struktur og utseende De tidligste utgavene av html var en blanding av strukturelle (f eks <h1> og <p>) og utsende (f eks <b> og <i>) merker. Dette henger ved i nye utgaver, selv i xhtml. Heldigvis har man fått CSS 1 som gjør at man egentlig nå kan klare seg med de strukturelle merkene. Dessverre var leverandørene av nettlesere sene med god støtte for CSS, men det begynner å bli bedre nå. Klarer man å begrense brukene av «utsende merkene» så oppnår man egentlig to ting. Man får en tekst som er lett å håndtere hvis den må flyttes til et annet system og det blir også enklere å endre formatering for et sett sider siden denne informasjonen er samlet på et sted. 1 Cascading Style Sheets Høgskolelektor Arnstein Gjestland 3

4 4 «Håndskrevet» html Spør man en profesjonell web-utvikler om hvilken html-editor som er best så svarer han «Notepad». Slik går historien og den hadde i alle fall et poeng opp til ganske nylig. Selv for å ivareta de enkle kriteriene som er beskrevet ovenfor var man ofte henvist til å skrive htmlkoden for «hånd». De store kommersielle web-editoren var ofte innrettet mot grafisk formgivning («se hva vi kan få til») mer en mot fornuftig, korrekt og tjenelig html merking 2. De siste årene har også disse editorene blitt langt bedre, men må vel sies å være «overkill» for enkle tekster. Mange benytter derfor fortsatt rene teksteditorer for å skrive webdokumenter. Mange av disse editoren har nå også blitt svært stabile og modne verktøy. Selv om den html man strengt sagt trenger å kjenne til for å produsere glimrende tekstdokumenter kan beskrives, og eksemplifiseres, på to til fire sider 3, så er de fleste brukere lite interessert i dette. Man foretrekker å benytte en tekstbehandler (typisk MS Word) og automatisk generer html dokumenter med et valg fra en meny. At dokumentene som blir generert er utrolig kompliserte og har en i beste fall sjaber kvalitet er det få som tar så tungt. 4 Heldigvis har det nå begynt å komme såkalte «Through The Web (TTW) authoring tools» 5. Dette er web-editorer som gjør at man kan skrive direkte inn i nettleseren. Denne teknikken ble først presentert av Microsoft i form av «DTML Editing Control» og attributten «CONTENTEDITABLE». Ideen ble tatt opp av Mozilla utviklerne og er nå også tilgjengelig i deres Mozilla og Firefox nettlesere. WYSIWIG teksten som man ser i editoren blir endret av selve layout-motoren («Gecko» alias NGLayout for Mozilla) slik at det man ser i editoren vil være identisk med slik teksten vil bli sende ut i nettleseren. Man vil til og med kunne se eventuell formatering spesifisert i CSS filer. For brukeren skulle derfor disse web-editorene oppleves som svært analoge til det man er vant til fra WISIWYG tekstbehandlere. Samtidig genererer en del av dem svært ryddig og standardisert html-koding, faktisk også dokumenter som validerer etter «xhtml strict». 5 Navigasjonssystemet Selv laget jeg mine første web-sider før de første grafiske web-editorene kom. Jeg var derfor henvist til å skrive html direkte i en teksteditor. Linkene mellom de ulike sidene måtte da også legges inn manuelt og hver gang man flytte på noe måtte linkene oppdateres. Brukte man relative og absolutte linker på fornuftig vis så var dette overkommelig, men det var et svært tidkrevende og møysommelig arbeid å sikre at alle disse interne linkene virket. Noen år senere kom de første editorene som forsøkte å automatisere denne prosessen vha såkalt «site management» funksjonalitet. Disse første editorene var ofte mer bry enn hjelp og jeg kan ennå huske frustrasjonen med å få Adobe Pagemill 1.0 til å virke på et vis. Det var rett og slett ikke verdt bryet. I dag er de fleste moderne web-publiseringssystemer mer eller mindre database baserte. Dette gir en helt annen mulighet til å ha dynamiske navigasjonssystemer. Dette innebærer at legger man inn et nytt objekt/html-dokument så opprettes det automatisk linker internt til dette dokumentet. I tillegg vil man kunne oppdatere eventuelle indekser som blir benyttet av søkesystemet. Tilsvarende vil man ha at hvis man fjerne eller flytter på noen innholdsbiter så 2 Det er ikke så mange år siden FrontPage skaffet seg mange uvenner ved å fikse på nøyaktig utformet html-merking bare man åpnet dokumentet (uten å lagre). 3 Se f eks 4 Det var kanskje fordi de får andre til å hjelpe seg når verket bryter sammen. Mer frustrerende arbeid enn å lete etter feil i Word-generert html-kode skal en lete lenge etter. 5 JISC har en utførlig gjennomgang av disse, se _report\_0308.html. Høgskolelektor Arnstein Gjestland 4

5 blir navigasjonssystemet oppdatert. Dette er selvsagt en langt bedre måte å organisere det hele på og må nærmest sees på som en nødvendig «feature» ved et moderne publiseringssystem. Eksterne linker er det selvsagt langt vanskeligere å ha kontroll over. Slik Internett er organisert må man neste regne med at eksterne linker til tider er utilgjengelig. Imidlertid vil et automatisk system for sjekking av eksterne linker kunne være til stor hjelp. F eks ved at det automatisk genereres rapporter over linker som har vært utilgjengelige de siste tre dager. Rapportene bør sendes til den som har ansvaret for de sidene hvor det linkes fra. 6 Hvor bør kompleksiteten ligge? Publisering av dokumenter på nettet vha http protokollen er en komplisert prosess. Den involverer http-servere, databaser, standarder, tegnsett, editorer, automatisk konvertering osv. Brukerne, både dem som legger inn innhold og dem som leser innholdet, skal selvsagt skjermes for dette. I tillegg til dette har man imidlertid en avveining av hvor kompleksiteten skal ligge. Moderne nettlesere har i dag innebygde «script» språk som kan utføre kompliserte oppgaver. En strategi er derfor å dele arbeidet ut til de ulike klientene (brukernes nettlesere) og la disse stå for en stor del av prosesseringen. En slik strategi ble ofte anbefalt tidligere fordi den skulle fordele belastningen. I dag ser man stadig oftere at det aller meste av arbeidet blir gjort på serveren som så sender ut ferdige html-sider. Fordelen med dette er at man kan ha systemer der brukeren kan jobbe over vanlig modem oppkobling fordi informasjonen som skal sendes blir mindre. For et system som skal distribuere innhold til en studentgruppe har man også den fordel at «support» blir mye enklere. Har studenten en nettleser som virker så skal sidene virke. Ved den første strategien risikerer man å bruke store ressurser på feilsøking og «support». Man må sikre seg at «scriptene» kjører på alle mulige kombinasjoner av systemer og nettlesere, eventuelt at sidene kan brukes selv om «scriptene» ikke skulle virke. Et annet alternativ, som man dessverre ofte ser, er å begrense bruken til én spesiell versjon av én spesiell nettleser. Dette er selvsagt en mulighet, men ødelegger mye av det som var tanken bak WWW. I tillegg vil det selvsagt kunne utelukke potensielle studenter eller gjøre kostnaden ved å følge et kurs unødvendig høy. I tillegg vil det ofte medføre dårligere teknisk kvalitet på innholdet, som igjen medfører store kostnader ved en eventuell oppdatering. Ofte ser man også at navigasjonssystemene lages vha utstrakt bruk av grafikk. Dette gjør dem selvsagt mindre egnet for studenter som sitter på trege oppringte forbindelser. I tillegg ser man ofte at det slurves med å benytte alt atributter for å angi innhold. Dette medfører at systemet lett blir ubrukelig for f eks en synshemmet person. Noe som egentlig er helt unødvendig. En uformell test som ofte anbefales, for å se om sidene holder mål, er å se på dem i den terminalbaserte nettleseren lynx. For den som ikke har testet sitt «verk» i en slik nettleser tror jeg nesten jeg kan love noen aha-opplevelser. Det kan være tilnærmet umulig å navigere rundt selv i små enkle nettsteder. 7 En og bare én versjon Særlig i en undervisningssituasjon vil det ofte være slik at innholdet opprinnelig er skrevet i en tekstbehandler el. Når dette innholdet skal distribueres over nett så må det konverteres 6. Dette innebærer imidlertid en fare for å få to, eller flere, versjoner av samme dokument. Det sier seg nesten selv at dette fort blir et mareritt å vedlikeholde, siden man alltid må passe på å 6 Enkelte systemer slik som f eks ClassFronter baserer seg imidlertid på å distribuere dokumentene i sitt opprinnelige format (MS Office/Open Office eller konvertert til pdf-format). Dette blir imidlertid mer som en filserver, som riktignok benytter http-protokollen og har en fin innpakning, men kan som vel knapt kan kalles en web-løsning. Høgskolelektor Arnstein Gjestland 5

6 gjøre en eventuell endring to steder. En ideell løsning ville selvfølgelig være «rundturkonvertering», f eks at man startet med et MS Word dokument, konverterte dette til html etter en av w3c standarder og så kunne konvertere fra dette tilbake til et word-dokument eksakt lik det man startet med. Slik situasjonen er i dag er dette ikke en utopi en gang og man skal være glad hvis man klarer en fornuftig konvertering én vei, f eks fra MS Word til validerbar html 7. Et av problemene er at disse kontorstøtte fil-formatene er binære og ofte svært kompliserte, har lite eller dårlig offentlig tilgjengelig dokumentasjon og en lang historie av «fikser» 8. Å få til en perfekt konvertering av disse formatene har derfor vist seg svært vanskelig. En alternativ rute som ofte har blitt benyttet for MS Word dokumenter er å eksportere i RTFformat og så foreta en konvertering fra RTF til HTML/XHTML. En tredje mulighet er å benytte MS Word sin mulighet for å eksportere i XHTML format. Generelt kan en vel si at MS Word html-dokumenter har et frynsete rykte. Særlige de første versjonene produserte html-kode av dårlig kvalitet. De nyeste versjonene genererer bedre kode, men fremdeles validerer den sjelden. Noe av årsaken er nok at MS Word er forsøker å gjenskape så mye av utseende som mulig og har nedprioritert strukturen. En enkelt test med et dokument som validerer 9 viser at dokumentet etter å ha blitt konvertert av MS Word nå har 121 feil 10. Nedenfor er også angitt to utsnitt av html-koden som dekker den samme delen av teksten (orginalen først). For å avhjelpe dette finnes det egne programmer og «scripts» som forsøker å rydde opp i html-kode generert av MS Word. <h1>har vi utf-8 nå</h1> <p> Her kommer litt brødtekst: æøå ÆØÅ og «æøåæøå» </p> <p>tester også %, $, #, & og ". Hvordan går det med disse og hva gir test.</p> <!-- Documents in footer --> <div class="css"> <b>dokumenter:</b> Konvertert av MS Word <h1 style='margin-right:29.75pt;margin-left:29.75pt'> <span lang=en-us style='color:black'><!-- /Folders in header --> Har vi utf-8 nå<o:p></o:p> </span></h1> <p style='margin-right:29.75pt;margin-left:29.75pt'> <span lang=en-us style='color:black'>her kommer litt brødtekst: æøå ÆØÅ og «æøåæøå» <o:p></o:p></span></p> <p style='margin-right:29.75pt;margin-left:29.75pt'> <span lang=en-us style='color:black'>tester også %, $, #, & og ". 7 Gullstandarden for om man har lykkes med å skape web-dokumenter av høy teknisk kvalitet er at de validerer mot w3c valideringstjeneste 8 MS Word feirer vel 20-års jubileum neste år Dokumentet er lest inn vha kommandoen Open web page... i Word:mac for macosx. Høgskolelektor Arnstein Gjestland 6

7 Hvordan går det med disse og hva gir test <o:p></o:p></span></p> <div style='border-top:solid #CCCCCC 1.0pt; border-left:none; border-bottom:solid #CCCCCC 1.0pt; border-right:none;padding:0cm 0cm 0cm 0cm; background:#f6f6f6'> <p class=msonormal style='margin-top:0cm; margin-right:29.75pt;margin-bottom: 2.0pt;margin-left:29.75pt;border:none; mso-border-top-alt:solid #CCCCCC 1.0pt; mso-border-bottom-alt:solid #CCCCCC 1.0pt;padding:0cm; mso-padding-alt:0cm 0cm 0cm 0cm'><span lang=en-us style='font-size:12.0pt;color:black'><b> <!-- Documents in footer -->Dokumenter:</b></span> En praktisk løsning på problemet er å konvertere tekstbehandlingsdokumentet til html-kode og samtidig legge inn en link til det originale dokumentet. En slik løsning vil sikre flere ting samtidig. Man vil gi studenter uten de relevante programmene en mulighet, de som ønsker kan laste ned originaldokumentet og en eventuell oppdatering kan skje ved at man laster ned originaldokumentet. Man endrer så dette før man konverterer på nytt. Et aktuelt program som kan konvertere ulike MS Word format til html er wvware 11. Selv om MS Word konvertering av html-kode ikke er optimal så blir den visuelle formateringen bra. Altså kan man med godt resultat konvertere et strukturert html-dokument til et tekstbehandlingsdokument. En mulig strategi ville derfor være å «omdøpe» et dokument fra et MS Word tekstbehandlings dokument til et web-dokument. Hovedversjonen som redigeres kunne da være web-dokumentet og så hentet man dette inn fra nettet og lagret det som et tekstbehandlingsdokument når man hadde behov for dette. Man kan også tenke seg at andre former for konvertering er aktuelle. Et eksempel er å konvertere strukturerte html-dokumenter til et format som er mer leservennlig. Selv om man har hatt store vyer om det «papirløse samfunn» så foretrekker nok de fleste å lese en lengre tekst i papirutgave. Selvsagt kan man direkte skrive ut web-dokumentet, men dette gir sjeldent noe strålende resultat. Har man derfor et større web-dokument, som er skrevet på weben og kun «lever» der er det aktuelt å konvertere dette til noe som er mer egnet for papirutskrift. Jeg vil senere vise et eksempel på en automatisk rutine som konverterer webdokumenter til PDFLaTeX 12 dokumenter som egner seg for utskrift. Igjen vil man ha kun én versjon, web-dokumentet, som oppdateres og dette kan så automatisk konverteres til pdf ved behov. 8 Matematikk, webens «grimme elling» Problemene beskrevet ovenfor blir for ingenting å regne i forhold til dem man får hvis man vil presentere matematikk på weben. Standarden MathML har eksistert i lengre tid men har hatt liten eller ingen støtte i nettleserne. Dette har blitt mye bedre de siste årene og særlig mozilla nettleserne skal ha brukbar støtte hvis de rette fontene installeres. Fremdeles er det imidlertid 11 Se 12 PDFLaTeX er benyttet til a sette dette dokumentet Høgskolelektor Arnstein Gjestland 7

8 mangel på gode verktøy for å produsere MathML kodet matematikk. MathML er også designet for å genereres automatisk av et verktøy og er derfor tidkrevende å skrive for «hånd». I tillegg er det også her et spørsmål om hvilken kvalitet MathML vil gi i en «papirversjon». Et alternativ som derfor ofte har blitt benyttet er at man har skrevet dokumentene i TeX/LaTeX format og så konvertert dem til web-dokumenter vha programmer som latex2html eller tex4ht. Matematikken har da blitt konvertert til bilder som har blitt flettet inn i teksten. Det kan ofte bli snakk om flere hundre, for ikke å si tusener, av bilder som må genereres. I tillegg er man avhengig av at prosessen virker perfekt. Må man inn å «fikse» manuelt på web-versjonen har man fort to parallelle versjoner av dokumentet som må vedlikeholdes. Det finnes nå verktøy som forsøker å konvertere fra TeX/LaTeX lignende formatering (itex) til MathML 13. Fremdeles er det imidlertid en stor utfordring å presenter matematikk som web-dokumenter. Den løsningen som ofte blir valgt er derfor å generere pdffiler f eks vha PDFLaTeX og så distribuere disse wha web-sider. 9 LAMP Ovenfor er skissert noen av de problemstillingen en står overfor når man som foreleser ønsker å distribuere innhold vha web-sider. Nå vil jeg også diskutere litt nærmere noe av den teknologien som kan benyttes for å lage løsninger. Det finnes utrolig mye å ta av, så for å begrense det litt vil jeg konsentrere meg om såkalte «open source» løsninger. Altså systemer/programmer hvor kildekoden er fritt tilgjengelig. En forkortelse man ofte ser i denne sammehengen er LAMP, som vel egentlig står for Linux, Apache, MySQL og PHP. Alt dette er verktøy som ofte blir benyttet for å sy isammen dynamiske web-systemer. Linux er da operativsystemet, Apache web-serveren, MySQL er databasen og PHP er «script» språket som binder det hele sammen. LAMP benyttes imidlertid løselig så L-en kan gjerne stå for OpenBSD, FreeBSD, netbsd eller i den senere tid også macosx/darwin. Tilsvarende kan M-en gjerne stå for PostgreSQL som database og P for perl, python etc som «script» språk. Ved hjelp av disse verktøyene er det bygd en mengde av ulike portaler (eng: portals), CMS-er (Content Management Systems), SMS-er og LMS-er. Mange av dem blir distribuert som åpen kildekode. For å illustrere et system som prøver å ta hensyn til noen av de forholdene som ble nevnt ovenfor har jeg bygd et en prototype ( Denne prototypen benytte OpenBSD, Linux, Apache og Zope 14. Apache kjører på Linux-maskinen, mens Zope kjører på OpenBSD maskinen. At det ble slik skyldes at jeg er midt i en ombygging av systemene og det naturlige ville være å kjøre det hele på en maskin. Systemet er satt opp slik at Apache tar seg av all innkommende trafikk på port 80 og sender det så videre til zope vha mod_proxy som er en apache modul. Zope er selv et byggesett for web-applikasjoner som består av en objectbasert database som er integrert med en web-server. Apache er derfor på sett og vis et overflødig ledd men gir stor fleksibilitet og økt sikkerhet. Prototypen er satt opp som en virtuell «host» og på Zope forgår en omskriving av urlene slik at de ser ut til å stamme fra en ordinær web-server. Zope er altså en kombinasjon av en web-server og en objektorientert database integrert i et system. Det meste av systemet er skrevet i språket Python, men det er også mindre deler som er skrevet i C av ytelseshensyn. Zope benytter dokument/mappe metafor og benytter URL-ene 13 Se for en slik plugin som kan brukes med Movable Type ( gir et interessant eksempel på bruk av et slik verktøy. 14 For mer informasjon om Zope se Det finnes også en stor online lærebok som har adressen Høgskolelektor Arnstein Gjestland 8

9 som oppslag i databasen. Dette sikrer at man, i motsetning til mange andre databasebaserte løsninger, beholder meningsfylte web-adresser slik som som kan leses som objektet andre.html i mappen webdavtest. Zope har også et system kalt «Acquisition» som går ut på at hvis den ikke finner et objekt i den mappen som blir kalt så forsøker Zope å finne objektet lengre opp i mappe-hierarkiet. Dette er svært nyttig f eks hvis man skal bygge et fleksibelt navigasjonssystem. Dette kan defineres som et objekt i den øverste mappen (rot-nivået) og vil så bli benyttet av alle objekter lengre ned i mappene. Får man behov for å overstyre dette kan man plassere et objekt med samme navn lengre nede i mappehierarkiet. Dette vil da bli funnet først for alle objekter fra denne mappen og nedover. Det klassiske «script» språket i Zope er DTML (Document Template Markup Language) og spiller samme rolle som f eks PHP og ASP gjør i andre løsninger. DTML kan sees på som et «ekstraspråk» som «rendres» til HTML før det endelige html-dokumentet sendes til leseren. DTML led imidlertid av samme problem som andre slik språk, de blir «ødelagt» av webeditorer. Enten må man ha en web-editor som er laget for å forstå og aksepterer dette «ekstraspråket» eller så må man først lage designet i en grafisk web-editor. For så å DTMLifisere dette HTML-dokumentet for å gjøre det dynamisk. Etter at dette er gjort kan man ikke ta det inn igjen i den grafiske web-editoren. Disse problemene har ført til ZPT (Zope Page Templates) som er ment å skulle ta over for DTML. ZPT er særlig ment for design av sidene og er mer begrenset enn DTML når det gjelder rutiner og logikk. Dette er gjort bevisst fordi det skal være lettere å skille logikken (som skal dekkes av PythonScipt) og «mark-up». ZPT er også designet som attributter til standard html-merker. Årsaken er at de aller fleste grafiske web-editorer simpelten ignorerer attributter de ikke kjenner. En side satt opp med ZPT kan derfor tas inn i en grafisk editorer uten at siden ødelegges. Nedenfor er gjengitt et eksempel på ZPT og atributtene som begynner med tal: tilhører ZPT. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " <html xmlns=" lang="nb" xml:lang="en"> <head> <title tal:content="here/title_or_id">the title</title> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <tal:dummy replace="python:request.response.setheader ('Content-Type', 'text/html;charset=utf-8')" /> <link rel="stylesheet" type="text/css" href="/nvutek.css"/> </head> ZPT kombinert med PythonScript gjør at man kan lage strukturerte dynamiske sider som validerer. Zope innholder også en «management interface» gjerne kalt zmi som man benytter for å lage både innhold og til å sy i sammen selve web-applikasjonen. I tillegg har Zope innebygd både ftp og webdav servere som kan benyttes til å legge inn innhold. Det er også mulig med tilleggsmoduler å få direkte tilgang til filsystemet slik at man slipper å forurense databasen med f eks multimedia innhold. Den tradisjonelle måten å legge innhold inn i Zope har vært gjennom tekstfelt i «Forms». I figur 1 er det vist et eksempel. Høgskolelektor Arnstein Gjestland 9

10 Figur 1: Tekstboks for å legge inn innhold. Viser også et eksempel på dtml merking. I det siste har det imidlertid blitt tilgjengelig TTW editorer som gjør at man kan skrive inn innhold som man gjør i en WYSIWIG tekstbehandler. Det er nettleserens «html-motor» som benyttes for å «rendre» html-koden så det man ser i editoren skal være WYSIWIG. De tar også hensyn til eventuelle CSS filer. I figur 2, nedenfor, er det angitt et eksempel der Epoz er benyttet. Figur 2: WYSIWIG editor for å legge inn innhold. Her editerer vi direkte i dokumentet. Teksten er et klipp fra statistikkprogrammet R. Den er formatert vha. css for å illudere en terminal med svart bakgrunn og grønn tekst. Merk at editoren er gjort spesielt liten her for å passe i bildet. Høgskolelektor Arnstein Gjestland 10

11 Figur 3: Figuren viser den ferdige siden i nettleseren Safari. Her ser vi også navigasjonssystemet og en rekke «knapper» for å legge inn nytt innhold. Høgskolelektor Arnstein Gjestland 11

12 I figur 3, er siden vist i nettleseren safari. I tillegg ser vi navigasjonssystemet. Dette genereres automatisk hver gang en side vises. Det gir lenker til dokumentene i samme mappe og også lenker til eventuelle under-mapper. I tillegg er det en såkalt «brødsmule sti» med lenker som gjør det lett å se hvor man er i systemet og også å flytte seg oppover i strukturen. Helt nederst i figuren ser en rekke med «knapper» som har følgende funksjon: Login : Denne knapper leder til Zopes innebygde administrasjonssystem (gjerne kalt zmi). Dette benyttes for å legge inn nye objekter, oppdatere eksisterende objekter, styre rettigheter og definer brukere, administrasjon av tilleggsprodukter og vedlikehold av selve databasen. Man har også muligheter for å kopiere, flytte, endre navn på og slette objekter. Zope benytter en transaksjonsbasert database, dvs den registrerer endringer slik at man kan «spole tilbake»/omgjøre eventuelle mindre heldige endringer. Nytt dokument :Oppretter et nytt innholdsobjekt klart for WYSIWYG-editering. Ny mappe : Oppretter en ny mappe satt opp med et standard dokument klart for editering. Dokumentet har navn «index_html» og vil bli vist som standard ved oppslag i en mappe f.eks Nytt navn på mappen : Gir mulighet for å endre navn (tittel) på nåværende mappe. Merk at Zope benytter både «id» og «title». «id» benyttes ved oppslag i databasen og finnes igjen i URL-ene, mens «title» er objektets tittel og benyttes som lenkenavn i navigasjonssystemet. Endre dette dokumentet : Endre det dokumentet vi ser på i WYSIWYG editoren. Nytt bilde : Brukes til å laste opp nye bilder i systemet. Opp ett nivå : Går rett og slett bare opp til «mor-mappen» til nåværende mappe. De fem knappene i midten er det man trenger for å legge inn nytt innhold. For å slette, kopiere eller flytte innhold må man benytte zmi eller f eks webdav. Det siste er nok det letteste for en bruker uten noe trening. Dette gir en tilgang til databasens objekter som er helt analog til den man har når man jobber mot filsystemet. I figur 4 er vist et eksempel på flytting av mappen «testfolder» et nivå opp i strukturen. Endringer gjort via webdav vil automatisk og momentant bli fanget opp av navigasjonssystemet. Høgskolelektor Arnstein Gjestland 12

13 Figur 4: Bildet viser flytting av en mappe vha. webdav. Endringene vil vises neste gang websiden lastes, siden navigasjonssystemet bygges dynamisk. Helt øverst i figur 3 ser en to knapper som har følgende funksjon Nvutek : Dette er bare en lenke til øverste nivå eller «home page». Den er lagt inn her fordi det ofte blir fremholdet som et krav for «usability». Lag pdf : Denne knappen genererer dynamiske pdf-versjoner av dokumentet. Dokumentet, ekslusive navigasjonssystem, blir konvertert fra xhtml til LaTex format. Dokumentet blir så kjørt gjennom pdflatex som returnerer den ferdige pdf-filen. Har man en «pdf-plugin» vil dette vises direkte i nettleseren og man kan lagre den eller eventuelt skrive den ut. Dokumentet vil da være satt av PDFLaTeX som gir en helt annen kvalitet enn det en nettleser kan prestere. Her er det altså web-dokumentet som er originalversjonen, som blir oppdatert. Pdf-versjonen blir generert dynamisk ved behov og lagres ikke noe sted i systemet. Prototypen beskrevet ovenfor viser et enkelt lite system der en direkte i nettleseren kan skrive inn i en WYSIWYG editor og genererere xhtml. Systemet kan selvsagt utvides med andre «produkter» (Zopes navn for tilleggsmoduler) slik som NuxDocument ( som gir konvertering av MSOffice og OpenOffice dokumenter til html RsessionDA ( som integrerer statistikk pakken R i Zope. fcforum ( Et diskusjonssystem for zope zwiki ( et wiki system for Zope Totalt skal det eksistere en ca 700 slike produkter for Zope, og tallet bare øker. I tillegg kunne det være interessant å se om man kunne få til en automatisk konvertering av LaTeX- Høgskolelektor Arnstein Gjestland 13

14 dokumenter vha Zope og f eks TeX4ht ( men det er et større prosjekt som det ikke er tid til her. Som nevnt ovenfor blir den terminalbaserte nettleseren Lynx ofte anbefalt for å se om nettsider er fornuftig merket. I figur 5, nedenfor, er det gjengitt et skjermbilde fra prototypen. Figur 5: Skjermbilde fra den terminalbaserte nettleseren Lynx. Som en ser blir teksten fornuftig gjengitt, også de særnorske bokstavene selv om UTF-8 er benyttet som tegnsett. 10 Standarder for e-læring Ovenfor er det diskutert hvordan man kan bygge systemer som forsøker å generere innhold som vektlegger struktur fremfor utsende. Dette bryter med tankegangen for WYSIWYGtekstbehandlere, men gir dokumenter som samsvarer mer med filosofien bak html/xhtml. I tillegg til dette må man imidlertid ha i tankene et stadig økende antall av e-lærings standarder slik som LOM, SCORM, IMS Content Packaging etc. Prototypen beskrevet ovenfor har selvsagt ikke støtte for noen av disse, det er imidlertid prosjekter i gang som kan resultere i støtte for flere av disse standardene f.eks eduplone ( og zope4edu og også connexions ( som ikke forsøker å følge disse standardene, men som likevel har noen av de samme mål. SCORM har blitt et skikkelig «buzzword» innenfor e-læring og tanken om SCOer («Shareable Content Object») som kan settes sammen til kurs og den tilhørende Legometaforen er utvilsomt forlokkende. Den senere tid har denne metaforen fått tildels hard medfart så nå er det atomer og mat-oppskrift 15 som råder. Hovedpoenget er uansett at små selvstendige moduler (SCO-er) skal kunne kombineres til hele kurs. Disse modulene skal være selvstendige i den forstand at de ikke skal referere til andre moduler. Innen fagmiljøet er 15 Se An Introduction to ADL and thescorm som kan nås fra academiccolab.org/learn. Modulen skal også kunne lastes ned slik at man kan studere og prøve seg frem med en SCORM-modul. Høgskolelektor Arnstein Gjestland 14

15 det diskusjoner om dette utgangspunktet er fornuftig 16 rent pedagogisk. Jeg vil her konsentrere meg mer om enkelte tekniske svakheter ved SCORM 17. Den alvorligste svakheten er nok at selv om SCORM benytter http som protokoll så bryter den med noen av de viktigste konvensjonene som er etablert på web-en nemlig «bokmerker» og «tilbake» knappen. En SCORM-modul vil derfor, selv om den vises i en nettleser, oppføre seg annerledes enn vanlige nettsider. I tillegg har SCORM dårlig støtte for å skille struktur og utsende. Dvs eventuell formgivning må skje inne i selve «assests». Følgelig kan det være en omstendelig og kostbar prosess å sy SCO-er sammen med en konsistent formgivning. Generelt sitter man vel med et inntrykk av at SCORM bærer preg av at mange av støttespillerne har bakgrunn i klassisk instruksjonsprogramvare som ble distribuert på fysiske medier som diskett og CD. Selv om man har skiftet til «nettet» som distribusjonsmedie ønsker man å ta med seg det man hadde uten å ta inn over seg at «nettet» har helt andre konvensjoner. Egentlig likner det litt på situasjonen man hadde når grafiske designere ønsket å overføre sine konvensjoner fra sideombrekkingsprogram til «nettet». Resultat var i starten ofte lite vellykket, men har gått seg noe til over tid. Kanskje kan man håpe på noe av den samme utviklingen når det gjelder SCORM. At det synes å eksisterer enkelte grunnleggende tekniske problemer med SCORM er imidlertid ingen unnskyldning for ikke å teste det ut og prøve seg frem. Som nevnt ovenfor har man tilgang til en eksempelmodul på Videre finner man masse dokumentasjon f eks på og som tilbyr både en SCORM-editor og «SCORM-player». I tillegg til enkelte teknisk «småplukk», som diskutert ovenfor, så har man et langt større og alvorligere problem med standardiseringsarbeidet innen e-læring. Dette kan kanskje oppsummeres som slit/nytte-faktoren. All standardisering for gjenbruk, om det nå er enkel koding med metadata eller mer ambisiøse prosjekt som SCORM, vil kreve en ekstra innsats hos innholdstilvirkeren for å lette gjenbruk hos andre. For kommersielle innholdsleverandører, og også spesielle utviklergrupper ved større utdanningsinstitusjoner, er nok ikke dette noe stort problem. Skal man få til et bredt og godt tilbud av innholdskomponenter er man nok imidlertid avhengig av at fagfolk ved universiteter og høyskoler gjør sitt undervisningsmateriell tilgjengelig. For den enkelte fagperson kan det å få ferdig en bit undervisningsmateriell innen det skal brukes være stor nok utfordring i en travel hverdag. Spørsmålet er altså om man orker den ekstra innsats som skal til for at andre lettere skal kunne benytte ens bidrag. Her vil selvsagt ulike incentiv-mekanismer kunne spille en rolle, men som for alt annet, er det nok svært viktig at ekstraarbeidet ikke blir for stort. Enkelte har derfor startet diskusjonen om kanskje spesifikasjonene, som nå er i ferd med å bli standarder, kanskje er for ambisiøse og/eller ikke funksjonelle 18. Et alternativ som ofte nevnes er RSS 19. RSS er i alle fall en meget enkel løsning som har blitt svært populær de siste årene. En ting er sikkert og det er at skulle RSS vinne frem som en løsning så er det ikke første gang møysommelig utarbeidet standard har blitt gjort irrelevant av en enkel løsning som virker «godt nok». 16 Se f eks Jaakkola og Nirhamo Who Forgot the Learner docs/who_forgot_the_learner_jaakkola_&_nirhamo.doc 17 Se Dynamic Appearance Model Analysis and Alternatives av Roger St-Pierre og Peter Hope ( for en inngående analyse av disse problemene og også forslag til endringer i SCORM. 18 Se f eks bloggerize_elearning.html. 19 Se f eks for en introduksjon. Høgskolelektor Arnstein Gjestland 15

16 11 Utviklingen innen e-læringssystemer Litt forenklet kan man kanskje si at man opp til ganske nylig har hatt en situasjon innen e- læring preget av en todeling. På den ene siden har man hatt kommersielle leverandører og større organisasjoner som har tendert mot kommersielle system og arbeid mot spesifikasjoner og standarder. På den andre siden har man hatt institusjoner innen høyere utdanning der e- læring har vært preget av eksperimentering og utvikling. Innen høyere utdanning har det hele også vært preget av en stor grad av fragmentering. I den senere tid har utdanningsinstitusjonene, iallfall her hjemme, i mye større grad begynt å ta i bruk kommersielle SMS/LMS-er. Et særtrekk ved disse systemene er at de er lukkede, dvs man må være definert som bruker for å få tilgang. Dette vil i utgangspunktet føre til en kraftig reduksjon i gjenbruk. Tidligere da det mest av læringsmateriellet lå på åpne web-servere kunne man «låne» ideer eller lenke direkte til interessant materiell. Denne muligheten er nå kraftig redusert. Kanskje kan man få til et system der den tapte muligheten for gjenbruk kan bli erstattet av en mer formalisert «bytte-økonomi» der standardiserte læringsobjekter kan utveksles. Om dette er realiserbart er for tiden høyst usikkert. I tillegg har det vært rapporter om at utvekslingen av slike læringsobjekter mellom de ulike e-læringssystemene ikke er smertefri. Selv om systemene i seg selv sies å være SCORM-kompatible så har leverandørene sørget for å legge inn tilleggsfunksjonalitet som vanskeliggjøre denne utvekslingen. Dette fører selvfølgelig til at «bordet fanger» og man kan bli låst til en leverandør. Det blir neppe noen lett jobb å flytte titalls gigabyte med innhold ut fra et slik system, hvis behovet skulle oppstå. Et helt nytt, stort initiativ innen e-læring er sakai ( Dette er et prosjekt der University of Michigan, Indiana University, MIT, Stanford, uportal Consortium og Open Knowledge Initiative (OKI) har gått sammen om å utvikle et nytt «open-source» e- læringssytem. I tillegg har de et «Partners Program» for andre aktører. Institusjonene vil ta med seg egenutviklede løsninger, og tanken er å bygge dette sammen til et omfattende system. Sakai har blitt fremholdt 20 som et prosjekt som har potensial til å bli en «apache» for e-læring. 12 Konklusjon Vi har ovenfor sett litt på ulike standarder som man må forholde seg til når man benytter «web-en» som et verktøy. På den ene siden har man de generelle standardene for webdokumenter, som dessverre ofte blir ignorert. På den annen siden har man begynt å få et sett av spesielle e-læringsspesifikasjoner og også standarder. W3c sine standarder gir en grunnleggende sikkerhet for at det innholdet man har utviklet kan benyttes i ulike nettlesere og kan konverteres til andre formater hvis behovet skulle oppstå. Når det gjelder e- læringsstandardene er det nok ennå et spørsmål hvilket gjennomslag de får og hva som virkelig kommer til å bli brukt. Uansett er gjenbruk i vår interesse og det lureste man kan gjøre er nok å eksperimentere med de verktøy som finnes. Det er den eneste måten å finne ut om de holder mål. 20 Se Høgskolelektor Arnstein Gjestland 16