OM PROSJEKTET-Gruppe 1

1. Deltakere og de forskjellige arbeidsområdene:

Elin Thonander Mikkelsen: Jobber til daglig med grafisk design og interaksjonsdesign. Har laget malen for oppsettet til historien og det meste av grafikken.

Elna Løvendahl Mogstad: Har ingen tidligere erfaring med web-design. Har bidratt mye til det pedagogiske innholdet.

Norveig Anderssen: Jobber som systemutvikler og har gjort det meste av kodingen i javascript.

Alle har bidratt på alle fagområder.Vi har samarbeidet godt, tross våre ulikheter, og fordelt arbeidet nogenlunde likt.



Vedlegg:

Interaktivt Eventyr - startside
Pdf av nettstedskart
Litteraturliste

2. Teori:

For å belyse teorien opp mot vårt prosjekt, fant vi at Barner-Rasmussen´s artikkel: "En model for analyse og produktion af hypertekst" og Gunnar Liestøl´s artikkel: "Datamaskinens utvikling til multimedium" er mest aktuelle. I tillegg har vi brukt læreboken "Effective Website Development" av Keith Darlington, som oppslagsverk i forhold til kodingen. (Litteraturliste)

Vårt prosjekt er ikke en ren hypertekstoppgave, men som vi avklarte i forprosjektet, beveger vi oss i grenselandet historie/spill, et hypermediaprosjekt.
Rolf Borgen Guescini ga oss en god definisjon: Hypermedia = multimedia + hypertekst.
Vi ønsker å gi brukeren en opplevelse, ikke bare formidling av informasjon. Dette har vi greid ved å bruke mye grafikk, lyd og satt tekster som passer til de forskjellige sidene. Dette er også vårt argument for å bruke transitional istedenfor strict XHTML, noe vi kommer nærmere inn på senere i teoridelen. I denne forbindelse vil vi nevne at vi har fått god forståelse av nødvendigheten med å benytte strict XHTML gjennom å ta dette kurset. Vi har validert våre sider via W3C sine sider.
Vårt prosjekt har blitt et interaktivt eventyrspill, uten at det skal settes i en bestemt "bås".

Barner-Rasmussen sier at det er viktig å avklare til hvem, om hva og hvorfor vi skriver. Han sier videre at det er ikke verktøyet som skal bestemme produktet, men det er produktets behov som skal bestemme verktøyet. Vi har sagt noe om dette både i forprosjektet og under avklaringer i teoridelen. I tillegg vil vi nevne at Barner- Rasmussen har laget en modell for oppbygning av hypertekst, da denne har relevans for vårt prosjekt.
Han skiller mellom ressurs-hypertekst og milø-hyper-tekst, hvor førstnevnte har liten grad av brukerpåvirkning, mens miljø-hyperteksten tillater i ulik grad brukeren å påvirke innholdet i hyperteksten. Vi kan relatere vårt prosjekt til sistnevnte. Her sier han at forfatteren må ha en klar mening med hyperteksten, og da særlig i hvor stor grad man ønsker at brukeren skal være aktiv. Det er da viktig å vise brukeren tydelig hva han kan gjøre, ved å f.eks. ha gjennkjennelige måter å linke ting på. Vi mener å ha fått til akkurat det. Dette illustrerer han ved hjelp av å dele hyperteksten inn i tre topografier (Litteraturliste), og her passer vårt prosjekt til nettverks-topografien.
Barner-Rassmussen snakker også om forskjellige link-metodologier. Vi viser til Kåre Andersen`s forelesning, hvor dette er omtalt ( Forelesning Humit1730MN, Kåre A. Andersen 16.10.06).

Liestøl nevner Ted Nelson, "hypertekstens far" (Litteraturliste). Nelson så at hypertekst som skrift kunne organiseres på en ikke-lineær, interaktiv og brukerstyrt måte. Prosjektet Xanadu skulle realisere denne tanken. Vi tar med dette, da vi mener det er relevant for vårt prosjekt. Som nevnt senere, er vårt prosjekt en ikke- lineær historie.

Så sier Liestøl noe om hva som kan skape problem for hypertekstforfattere:" I det øyeblikket en åpner for brukerstyring og valgfrihet i tilegnelsen av informasjonen, svekkes forfatterens kontroll og mulighet til å påvirke leseren." Gunnar Liestøl omtaler senere det ikke- lineære, der hvor en bok har en lineær struktur, kan man ikke bruke det i en nettverksbasert struktur.

Vi har laget en ikke - lineær historie, dette kan også relateres til Vannevar Bush som mente menneskets hjerne ikke tenker i linjer, men vi tenker assosisiativt med stadig skifte av synsvinkel
( Forelesning Humit1730MN, Kåre A. Andersen 16.10.06).

I vår historie kan brukeren gå til forskjellige verdener frem og tilbake, det er ikke én vei til målet.
Vi har lagt inn at du minimum må gjennom to verdener for å komme til mål. Dette kan selvsagt gjøres større, men vår historie begrenser seg til 5 verdener totalt.

Liestøl sier:"Hypertekstlighet og brukerstyring har altså sine klare begrensninger og må benyttes med omhu.".
Videre går han inn på noe som passer vårt prosjekt godt. Disse begrensningene har funnet sin løsning i dataspill, hvor brukeren kan bevege seg innenfor rammene av tradisjonell historiefortelling, men ha friheten til å bevege seg fritt mellom f.eks ulike verdener.
Vår historie vil ikke egne seg på papir, da den er mest basert på grafikk og lyder, samt at strukturen for historien ikke er sekvensiell .

Avklaringer:

Målgruppen er 7 -10 år. Det er stor forskjell på en 7- og en 10-åring i hvor godt de kan lese. Derfor er det ulik vanskelighetsgrad på tekst og oppgaver i historien. Alle oppgaver skal kunne løses ved å prøve flere ganger, selv om man ikke forstår alt som står der. Dette for å kunne komme til mål. Videre har vi kun brukt store bokstaver i teksten, dette også fordi noen barn i denne aldersgruppen kun kan lese store bokstaver. Vi har underveis testet historien på nevnte målgruppe, og fått brukbare tilbakemeldinger.

Pedagogisk fokus:

Vi har gjennom hele arbeidet med prosjektet tenkt hvordan målgruppen kan få noe ut av eventyrspillet. Vi har lagt inn forskjellige spørreoppgaver, med ulik vanskelighetsgrad. Vi har også brukt noe tekst for å gjøre eventyrspillet fengende, denne er som før nevnt, skrevet med store bokstaver for å nå alle i målgruppen. Bruk av aktive bilder (billedlinker), tror vi også vil virke fengende på vår målgruppe. Vi mener vår oppgave ville egne seg godt på CD-rom, som et læringsverktøy. Her ville det kanskje vært nødvendig å utvide eventyrspillet, for å få inn flere læringsfokus.

Tekniske valg og problemer

Som beskrevet i forprosjektet ønsket vi å lage en helhetlig løsning som tok i bruk alle sanser. Dvs en multimedialøsning. Dette har ført til en rekke ting. For å kunne bruke lyd i løsningen tenkte vi å bruke taggene embed og object, og valgte derfor å bruke transitional XHTML fremfor strict, ettersom embed ikke validerer i strict. Etter en god del testing endte vi med å bruke taggen bgsound som ikke engang validerer transitional, men som i Internett Explorer fint viser hvordan vi ønsker at sidene skal virke. Ellers validerer sidene fint.
Løsningen fungerer godt i Internet Explorer som den er laget for. Den fungerer ikke så godt i andre nettlesere vi har testet. (Opera og Firefox) Her forskyves bildene noe. Javascriptkodingen virker heller ikke helt som den skal, og lydene virker ikke overhodet.
Et naturlig neste steg i prosjektet ville være å gjøre om sidene slik at de virker i flere nettlesere. Man måtte jobbet for å finne en løsning på problemet med lyd, bl.a. ved å unngå bgsound taggen som kun virker i explorer. Andre javascriptkoder må også gjennomgåes, og man må sannsynligvis skrive flere stilark som linkes inn avhengig av browser, slik at bildene blir riktig plassert.

Bruk av javascript i løsningen

Vi har benyttet javascript til følgende:

a) Lagre brukerens navn i en cookie, og hente det ut fra cookie'en seinere for å bruke det i en oppgave.
b) Validering av svar på oppgaver, ofte i kombinasjon med lydeffekter (se c).
c) Bruk av lyd-effekter. Her brukte vi den foraktelige bgsound, som fungerer i Internet Explorer. Vi bruker den IKKE til å spille kontinuerlig bakgrunnslyd, men til å slå av og på lyd ved å la src peke vekselsvis på en ikke-eksisterende fil og en eksisterende lydfil. Dette gjøres ofte i kombinasjon med "time-delays".

For seint oppdaget vi at bgsound ikke validerer hverken i transitional eller strict. Vi burde sannsynligvis brukt OBJECT istedenfor og så tatt utgangspunkt i de mulighetene vi ville hatt da.
Siden vi har brukt bgsound, vil lydeffektene heller ikke virke i andre browsere enn Internet Explorer. Man har mulighet for å programmere sjekk av hvilken browser som er brukt og så benytte bgsoud eller embed avhengig av dette. Vi har ikke prioritert å bruke tid på det.

Vi kunne samlet all javascripten på en egen .js-fil. Vi begynte med en slik løsning, men fikk problemer med at tilgangen til denne filen stadig måtte settes på nytt. Vi har derfor lagt all javascript som blir brukt på en side, både det som er spesiellt for siden og de mer generelle funksjonene, inn i selve dokumentet.

Vurdering av innholdet

Vi har satt opp fem verdener som en slags smakebit på mulighetene ved konseptet. Stort nok til å presentere konseptet, men ikke altfor uoverkommelig for størrelsen på prosjektet. Vi begynte med å sette opp et nettstedskart over hele strukturen, som vi har fulgt sånn nogenlunde, med avvik der vi syntes det var det beste for løsningen. Vi er fornøyd med innholdet og mener det er passende variert og spennende. I et større porsjekt kunne dette gjøres mye mer kompleks og enda mer variert. Vi mener vi har fått til en god helhet på løsningen, hvor alle sider bygger på samme mal. Sidene har en fast størrelse som passer 800*600 skjermer. Kanskje er det ikke lengre nødvendig å følge denne standarden, men vi har ikke sett behovet for større plass i denne omgang. Vi har valgt å bruke mye grafikk, som gir tunge sider å laste. Ikke det ideelle for noen som sitter og laster ned over vanlig telefonlinje, men ikke noe problem hvis systemet f.eks skal brukes til cd-rommer i læresammenheng. For barn i denne alderen som såvidt har startet sin lesekarriere, vil det visuelle og auditive være av minst like stor betydning. Vi har forsøkt å lage et helhetlig system, og mener vi har klart det ganske bra, med enkelte variasjoner som følge av at arbeidet er utført parallelt av ulike personer.

Navigasjon.

Vi har brukt lite vanlige tekstlinker, men lenket mye ved hjelp av "levende" billedlinker, samt små spørreoppgaver. Navigasjonen er relativt konsekvent med bruk av bilder som endrer seg ved mouseover, og skjemaer med svar via radiobuttons. Vi har et par avvik fra dette: Bruk av knapper uten radiobuttons i maskinverdenen, og bruk av bildelinker som ikke endres på mouseover i spøkelsesskogen. Vi har bevisst forsøkt ulike måter å gjøre det på. Dette skal tross alt være en opplevelse og et sted for utforskning, ikke en stram informasjonsløsning hvor man ønsker å finne frem fort. Dermed kan vi tillate oss mer avvik fra en fast form for navigasjon, og kanskje burde avvikene vært større og ikke mindre!? Mens f.eks engelsiden gjør det lett å se hvor man kan gå videre bare man beveger musa fort over siden og ser de store bildene endre seg, er spøkelseskogen vanskeligere (og mer mystisk) ved at man nærmest må scanne siden for å finne det lille området som linker videre fra fuglen i treet. Og hvor eneste indikasjon på at det er en link er at musepekeren endrer seg. Det er også her vi finner siste spørsmål før mål, så det er en logikk i at den skal være litt vanskelig å finne.

Tilgjengelighet og brukervennlighet.

Vi har forsøkt å utstyre alle bilder med beskrivende alt-tekster, slik at de skal kunne lese av alternative nettlesere. Der hvor tekst er lagt inn som bilder, har vi forsøkt å også oppgi denne informasjonen ved hjelp av alt-tekstene. Uten å ha testet det, vil vi tro at sidene skal kunne leses også av blinde med talesyntesenettlesere. Når det kommer til alternativt innhold i forhold til lyd er ikke løsningen like bra. Endel av oppgavene har lyd som eneste tilbakemelding, og gir dårlig tilgjengelighet, og forståelse av hva som skjer, ikke bare for folk med hørselsproblemer, men også for alle som mangler lydutstyr på datamaaskinen sin eller som rett og slett har slått av lyden. Noe som ikke er uvanlig. Disse tilbakemeldingene burde ha et alternativ som f.eks en tilbakemeldingstekst i tillegg.
Det er tilbakemeldingsituasjonene som gir de største brukervennlighetsproblemene. Det er greit å måtte lete seg rundt, og å være på søking etter veiene, men det må være tydelig når du har valgt feil, slik at brukeren forstår hva som skjer, og ikke får inntrykk av at alt er tilfeldigheter. Dette er spesielt viktig hvis en ønsker å bruke det i en pedagogisk sammenheng.
Vi har ikke laget noen hjelpfunksjon, ettersom dette er en utfordring som ikke skal være lett. Ønsker man å gi brukeren tips, kan dette gjøre si feltet øverst på hver side i den enkelte verden.

Hypermedia

Vi mener at dette prosjektet passer godt under begrepet hypermedia, ettersom vi lenker oss fra tema til tema ved bruk av flere medier (lyd, bilde, bevegelse, tekst). Brukeren blir sendt på en søken gjennom sidene på vei mot (et ukjent) mål. Prosjektet kunne kanskje vært enkelere utført i flash, hvor blandt annet mulighetene til å spesifisere formen på området som lenkes er bedre. Der står du også friere ifht utforming og bruk av fonter, grafikk plassering etc. Du omgår også problemene ved ulike browsere, ettersom flashplayeren er lik uannsettt browser. På den andre siden vil ikke løsningen bli like tilgjengelig ifht alternative nettlesere. Man vil også bli avhengige av at alle har innstallert en flashplayer i browseren sin, men i norsk sammenheng, og for denne målgruppen, er det stort sett ikke noe problem.

3. Résyme:

Vi har møttes jevnlig, hatt en plan som vi stort sett har klart å følge. Se Logg/Rapport- sidene via Classfronter: Innlevering av Oblig3.



Valid XHTML 1.0 Strict

Valid CSS!

Prosjektoppgave HUMIT 1730MN - Høsten 2006 - Elin Thonander Mikkelsen, Elna Løvendahl Mogstad, Norveig Anderssen.