Denne kravspesifikasjonen setter rammebetingelsene for prosjektet og utgjør sammen med oppgavebeskrivelsene vurderingskriteriene for evaluering og sensur. Eventuelle uklarheter i teksten bør du ta opp på labbene. Spørsmål om sensur kan du ta opp med foreleser på forelesningene.
Innleveringene skal sendes som e-post vedlegg til adressen inf5270+mappe@ifi.uio.no senest innen klokken 23:59:59 på innleveringsdatoen angitt i oppgaveteksten (typisk søndag kveld).
Innleveringene sendt til denne adressen vil bli behandlet maskinelt, og det er derfor svært viktig at man følger format-spesifikasjonene eksakt. I motsatt fall kan det i verste fall skje at innleveringen i sin helhet ikke blir lest og bedømt. Dersom en innlevering har feil format så vil vi selvsagt gi den det gjelder mulighet til å rette opp problemet. Ingen ting annet vedrørende kurset eller oppgavene skal sendes til akkurat denne adressen, heller ikke kommentarer knyttet til innleveringer, sykdom etc. (all post sendt til denne adressen blir kun lest maskinellt - og andre meldinger enn oppgaveinnleveringer vil neppe bli sett av noen).
Form på innleveringen uansett type:
mml-attach-file). Det er lurt å sende en kopi til seg
selv og sjekke at det fungerer korrekt.Oppgavene legger opp til tre typer innleveringer:
concat($brukernavn,$oppgavenummer,'.xml')
concat($gruppeid,$oppgavenummer,'.xml')
.tgz), med
XML-filer, HTML-filer (startsiden skal hete index.html),
CSS-filer, kildekode og dokumentasjon i form av ett
XML-dokument i spesifisert format. Filarkivet har navn på formen
concat($gruppeid,$oppgavenummer,'.tgz') og når det pakkes
ut skal alle filene ligge i en folder med navnet
concat($gruppeid,$oppgavenummer). Eksempelvis vil
tekstdokumentet i et programarkiv for en prosjektgruppe "hiphop" og
oppgavenummer 2 ha path'en hiphop2/hiphop2.xml etter
utpakking av arkivet. Startsiden (i eksempelet
hiphop2/index.html) skal lenke videre til lokale filer og
ikke til et programsystem som evt. befinner seg på gruppas hjemmeside.
Altså: bruk relative URLer. Alle filer i arkivet som er viktige for å
forstå og bruke systemet skal være lenket til fra startsiden
index.html med en kort beskrivelse, pass på at også
dokumentasjons-filen er lenket til fra denne startsiden.Alle tekstinnleveringer skal bestå av ett (NB!) XML-dokument. Dette gjelder både individuelle og gruppeinnleveringer. Dokumentet skal være basert på mal for innleveringer, gitt nederst på oppgaveteksten (se f.eks. Oppgave 1). Bruk UTF-8 tegnsettkoding og sjekk at det fungerer! Dokumentet skal bruke siste versjon av vårt XSLT stilark, som blir gjennomgått på labbene (se innleveringsformat).
Sørg for at alle dokumenter og foldere som sensor skal forholde seg til har filnavn på den formen som er angitt over. De riktige filnavnene blir også fremvist øverst på besvarelsesdokumentet ditt når du viser det på skjerm, forutsatt at XML-dokumentet ditt er korrekt.
Eventuelle bilder skal være lenket inn i dokumentet med elementet
<illustrasjon ... />, bruk full absolutt
URL. Bilder skal ligge på en av UiOs webservere på grunn av
konsistens- og backup-problematikk. NB! Pass på at disse elementene
fortsatt er tilgjengelig til etter at sensurperioden er
ferdig. Eventuelle illustrasjoner skal være lesbare på
utskrift i A4-format.
Valider dokumentet med XMLSpy ved å bruke det XML Schema som er angitt i malen neders på oppgaveteksten. Husk å sjekke at dokumentet ser riktig ut med Microsoft Internet Explorer versjon 6 eller senere. Sensor vil primært bruke denne nettleseren.
Ved utpakking skal et programsystem være kjørbart
fra startsiden index.html, som også skal
gi brukeren nødvendige instruksjoner for å få systemet til å virke.
Test at arkivet virker ved å pakke det ut og kjøre det lokalt fra en
annen konto før innlevering!
Prosjektets design og den skrevne argumentasjonen for designet skal demonstrere at prosjektgruppen evner å tenke konstruktivt rundt begrepene:
Prosjektets design, drøfting og implementasjon skal demonstrere at prosjektgruppen behersker følgende teknologier og at gruppen vet å nytte dem på en hensiktsmessig og profesjonell måte:
Designet skal være målrettet og realiseringen av designet skal vise at prosjektgruppen ser sammenhengen mellom de ulike teknologiene og hva de egner seg til. Implementasjonen skal harmonere med den underliggende filosofien bak standardene fra W3C og leve opp til grunnleggende anvendelighetsprinsipper (blant annet WAI ).
Gjennomføringen av prosjektet og den skriftlige drøftingen skal videre vise at gruppen har klart å bringe frem et design og en implementasjon som er egnet for utprøving med kursets evalueringsteknikker. Gruppen skal ha forstått hvordan evalueringen skal gjennomføres, samt styrkene og svakhetene til de ulike evalueringsteknikkene.
Andre teknologier som kan benyttes er JPEG, PNG, GIF og SVGT. Disse formatene skal kun brukes til fremvisning av informative bilder og ikke til hverken navigasjon eller ren dekorasjon.
Designet skal være tilgjengelig og anvendelige for alle brukere (se WAI ), eksempelvis personer som ikke kan bruke mus og er avhengig av tastatur, personer som bruker alternative nettlesere som er basert på braille eller lydsyntese, personer med liten skjerm, med videre. Det ferdige prosjektet skal med andre ord ha et hensynsfullt og web-ergonomisk design, men man kan anta at brukere av nettstedet har erfaring med web fra før. Dette tilgjengelighetsaspektet skal være drøftet i designdokumentasjonen.
Designet skal være fokusert og avgrenset. Avgrensning og fokus skal være klart definert og beskrevet på en kortfattet måte. Prosjektet vil bli vurdert ut fra sammenhengen mellom det beskrevne fokus og realiseringen. Alle elementer i det endelige designets brukergrensesnitt skal forankres i prosjektets fokus og avgrensning. Disse elementenes anvendelighet og hensiktsmessighet skal være egnet for evaluering, og de skal evalueres med brukertesting i prosjektets sluttfase.
Nettstedet skal støtte opp om sosial navigasjon og sosialitet. Tenk gjennom hva slags designelementer dere kan bruke for å støtte opp under dette. Disse designelementene skal være drøftet i designdokumentasjonen.
Designet skal gi informasjonen en struktur som setter brukeren i stand til å bevege seg mellom sidene på en naturlig og hensiktsmessig måte. Hva som er hensiktsmessige navigasjonsmønstre vil være avhengig av prosjektets tema og fokus. Typiske navigasjonsmønstre og navigasjonsstrukturer (hierarkisk, global, lokal/subsite, kontekstuell, m.m.) og hvordan disse reflekteres og brukes i det valgte design skal drøftes.
Det er opp til dere hvordan nettstedet er organisert (hierarkisk, kronologisk, alfabetisk, topologisk, oppgave-orientert, metafor-drevet, hybrid, m.m.), om denne organiseringen er åpen eller lukket. Den valgte organiseringen bør imidlertid begrunnes med utgangspunkt i nettstedets tema og fokus. Drøft gjerne den organiseringen som er valgt opp mot alternative løsninger.
Det er imidlertid et krav at når brukeren beveger seg mellom ulike websider så skal informasjonen være gruppert og presentert på en slik måte at brukeren får en følelse av å bevege seg mellom identifiserbare «steder» (places) som han har mulighet til å besøke igjen senere. Disse virtuelle stedene skal ha egenskaper som bidrar til at nettstedet som helhet får god sosialitet. Brukeren skal ikke få følelsen av å flyte rundt i et kaotisk informasjonsrom (information space). Det er altså ikke tilstrekkelig å designe en søkemotor.
Designet skal også tilby brukeren en overordnet oversikt over nettstedet (site map). En site map kan enten være organisert slik at den speiler organiseringen av nettstedet, eller den kan gi et helt annet perspektiv. Dere må selv velge perspektiv og begrunne valget.
Prosjektets design trenger hverken å være konsistent med eller å fungere sammen med designet til andre prosjektgrupper. Det er rom for uavhengig eksperimentering. Systemet trenger heller ikke å tilby funksjonalitet som utnytter alle muligheter som ligger i databasen, men alle metadata fra databasen kan benyttes dersom det er ønskelig, også metadata som man ikke kan legge inn gjennom deres grensesnitt.
Den funksjonaliteten som tilbys skal utgjøre en helhet og være innrettet mot prosjektets tema og fokus. Designet skal generelt ha god lesefunksjonalitet og støtte sosial navigasjon. Skrivefunksjonalitet bør være avgrenset til det som er essensielt for å få testet deres designidé. Det realiserte systemets skrive- og lese-funksjonalitet skal være egnet for høyttenkningsevaluering. Funksjonalitet som dere mener et fullverdig system bør ha, men som dere velger å ikke implementere, bør beskrives i designdokumentasjonen.
Designet trenger ikke å begrenses med tanke på overvåknings eller privatlivsproblematikk, men slike problemstillinger skal drøftes i designdokumentasjonen. Bruker skal også være informert om at systemet registrer informasjon om henne eller ham, enten i form av tekstlig beskrivelse eller ved at det gjøres reelt synlig for brukeren i designet. Metaforisk skal dette forstås slik at designet ikke skal benytte seg av «skjulte kamra», men gjøre enten registrering av informasjon eller den allerede registrerte informasjonen synlig for brukeren på en tydelig måte.
Det skal føres argumenter både for og mot designelementer for at designvalget kan krediteres ved sensur. Det er derfor en god ide å skrive opp både positive og negative argumenter fra diskusjoner knyttet til elementene i designet slik at argumentene senere kan innlemmes i en helhetlig drøfting når designdokumentasjonen skal skrives. Denne drøftingen skal gjennomgående knyttes opp mot prosjektets fokus innenfor de avgrensninger dere har angitt. Det er altså ikke nødvendig å føre argumenter relatert til forhold som ligger utenfor den avgrensningen dere har satt opp. Det er derfor viktig å finne en faglig fornuftig avgrensning for prosjektet.